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(i) REAL PARTY IN INTEREST 

The Assignee of all right, title and interest to the above-referenced Application 
Diebold, Incorporated, an Ohio corporation. 



(ii) RELATED APPEALS AND INTERFERENCES 

This application is a continuation-in-part application of U.S. Application Serial No. 
09/193,787 filed November 17, 1998 which is currently on appeal before the Board of Patent 
Appeals and Interferences. In addition, U.S. Application Serial No. 09/193,787 is a 
continuation-in-part application of PCT/ US97/21422 filed November 25, 199/ (now U.S. 
Application Serial No. 09/077,337) which is also currently on appeal before the Board of Patent 
Appeals and Interferences. 

It is believed that these other appeals do not directly pertain to the claimed subject matter. 
However, it is respectfully requested that the Board make its own determination regarding the 
pertinence of these other applications. Appellants, Appellants' legal representative, and assignee 
believe that there are no additional related appeals or interferences pertaining to this matter. 
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(iii) 



STATUS OF CLAIMS 



Claims 1-32 are pending in the Application. 



Claims allowed: none 

Claims confirmed: none 

Claims withdrawn: none 

Claims objected to: none 

Claims canceled: none 



Appellants appeal the rejections of claims 1-32. These claim rejections were the only 
claim rejections present in the Office Action ("Action") dated September 9, 2004, which was 
made non- final. Claims 1-27 have been twice rejected. 



Claims rejected: 



1-32 
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(iv) STATUS OF AMENDMENTS 

A non-final rejection was made September 9, 2004. No amendments to the claims were 
requested to be admitted after the non-final rejection. 
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(v) SUMMARY OF CLAIMED SUBJECT MATTER 

Concise explanations of exemplary forms of the claimed invention: 



With respect to independent claim 1 

An exemplary form of the invention is directed to a method. The method comprises the 
step of determining through operation of an automated banking machine, data corresponding to 
an entity with which a customer operating the machine has an account. Examples for this 
method step described in the Specification include the user having indicia corresponding to a 
system address on a card that is read by a card reader in the banking machine or other input 
device, which identifies the user or an institution or entity with which the user has an account 
(Page 9, lines 5-8). Figure 2 shows an example of an automated banking machine such as an 
ATM (12) which includes a reader such as a card reader/writer mechanism (38). 

As described at Page 25, lines 5-15 of the Specification, the address stored on the card 
may correspond to a uniform resource locator ("URL") address. This data corresponding to an 
address may be recorded on track 3 of a magnetic stripe or in other locations in the magnetic 
stripe data or through encoding other readable indicia on the card. Alternatively, if the 
customer's card is a "smart" card which includes semiconductor storage thereon, the URL 

arlHres^ associated with the nKtomgr mav be inrliiHed a^ T^arf of the ctnreH Hafp rvr» the inteorntpd 

circuit chip on the customer's card. 

In another embodiment (Page 25, line 16 to page 26, line 4; page 48, lines 1-15), the URL 
could be derived from other data on the card by accessing a database in which card data is 
correlated with address data. For example, a "bank identification number" (BIN) may be read 
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from a card. The automated banking machine may operate to resolve a network address from the 
card data by accessing a database which includes BIN data or other entity data correlated with 
network address data. 

In addition to the above described determining step, this exemplary form of the invention 
comprises the step of providing through an output device on the automated banking machine, at 
least one output uniquely corresponding to the entity with which the customer has the account. 
As discussed in the Specification at page 26, lines 1-7, the automated banking machine may use 
the network address obtained from the card or resolved form card data to access a server operated 
by the entity with which the user has an account relationship. HTML documents or other types 
of documents accessed at the address may provide interface screens and transaction flows from 
the customer's familiar home institution or entity, even though the machine the customer is 
operating is not controlled by that entity. 

Figure 3, shows an example of an HTTP home server (90) and a foreign server (96) 
which operate to deliver at least one HTML document to a browser (76) of the automated 
banking machine (12). Figures 19 through 22 graphically represent the operation of an 
exemplary system when a "foreign" user uses the ATM (12) (Page 48, line 1, page 54, line 21). 
Examples of output devices through which outputs from the browser are directed include a 
display device such as a touch screen (30) (Figure 2). However, the automated banking machine 
may include other types of output devices such as audio speakers (Page 13, lines 16-22). 
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With respect to independent claim 8 

Another exemplary form of the invention is directed to a method which comprises the 
step of reading card indicia on a card presented by a customer to an automated banking machine 
(12) (Figure 2). The card indicia includes entity data corresponding to an entity with which the 
customer has an account (Page 9, lines 5-8; Page 25, line 5 to page 26, line 4). An example of 
entity data read from a card may include a "bank identification number" (BIN). 

This described exemplary form of the invention also comprises the step of resolving 
network address data with the banking machine responsive to the entity data and data stored in a 
data store (Page 48, lines 1-15). In addition, this described exemplary form of the invention 
comprises operating a browser (76) in the banking machine responsive to the resolved network 
address data, to access at least one network address in a network. The network address accessed 
corresponds to an address of a server (90, 96) adapted to deliver documents corresponding to the 
entity with which the customer has the account. Figure 3 shows an example of an HTTP home 
server (90) and a foreign server (96) which operate to deliver at least one HTML document to a 
browser (76) of the automated banking machine (12). Figures 19 through 22 graphically 
represent the operation of an exemplary system when a "foreign" user uses the ATM (12) (Page 
48, line 1, page 54, line 21). 

As discussed in the Specification at page 26, lines 1-7, the automated banking machine 
may use the network address obtained from the card or resolved form card data to access a server 
operated by the entity with which the user has an account relationship. HTML documents or 
other types of documents accessed at the address may provide interface screens and transaction 
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flows from the customer's familiar home institution or entity, even though the machine they are 
operating is not controlled by that entity. 

With respect to independent claim 19 

Another exemplary form of the invention is directed to an apparatus comprising a 
plurality of institution servers (20-28) (Figure 1). Each institution server is associated with one 
of a plurality of financial institutions (Page 13, lines 8-15). Each institution server has at least 
one unique network address and each institution server is operative to deliver at least one 
document associated with the respective institution (Page 9, lines 12-18; Page 26, lines 1-7). The 
apparatus also comprises a network (14) in operative connection with each of the plurality of 
institution servers. In addition, in this described exemplary form of the invention, the apparatus 
comprises at least one automated banking machine (12) such as an ATM. As shown in Figure 2, 
the automated banking machine includes a computer (34) having a browser (76) operating 
therein, a card reader (38) and an output device (30) in operative connection with the computer 
(Page 13, line 16 to page 14, line 3). The automated banking machine is operative responsive to 
reading card indicia on a card read by the card reading device, to cause the browser to connect 
through the network to a network address of an institution server corresponding to the card 
indicia (Page 8, line 21 to page 9, line 18). Figures 19 through 22 graphically represent the 
operation of an exemplary system when a "foreign" user uses the ATM (12) (Page 48, line 1, 
page 54, line 21). 
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GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 

The grounds to be reviewed in this appeal are: 

Whether Appellants' claims 1-32 are unpatentable under 35 U.S.C. § 103(a) over 
Reisman, et al., U.S. Patent No. 6,594,692 ("Reisman") in view of Kolling, et al., 
U.S. Patent No. 6,385,595) ("Kolling"). 
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(vii) 



ARGUMENT 



Reisman (U.S. Patent No. 6,595,692 ) 

Reisman is directed to a computer-implemented information transport software module 
usable with any of multiple electronic information products for mass distribution of electronic 
information objects to users of a diversity of uncoordinated communications-equipped computer 
stations (Column 5, lines 1-6). In Reisman, typical communications equipment comprises a 
modem. However, Reisman also teaches that other communication cards and devices enabling 
remote communication between computers may be used, such as devices or means permitting 
communication in a digital rather than analog realm, for example, ISDN or ATM interfaces 
(Column 5, lines 57-62). Reisman also states that some equivalent networks which may be 
deployed over telephone network hardware, or interface therewith, include ISDN, ATM and 
ASDL as well as off-air services such as cellular or CPCD and as well as, cable television 
networks (Column 35, lines 40-45). 

As used in this context, Appellants respectfully submit that the term "ATM" is intended 
in Reisman to be an acronym for "Asynchronous Transfer Mode," which is a network 
architecture capable of very high transmission speeds. Such a definition for ATM is consistent 
with the other examples of network architectures such as "ISDN" (acronym for "Integrated 
Services Digital Network") disclosed along with the term ATM in Reisman. Reisman does not 
disclose or suggest automated banking machines such as automated teller machines (ATMs). 
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Appellants respectfully submit that Asynchronous Transfer Mode (acronym "ATM") 
disclosed in Reisman is non-analogous art with respect to automated banking machines such as 
automated teller machines (acronym "ATM") of the present invention. 

Rolling (U.S. Patent No. 6385,595 ) 

Rolling is directed to an electronic statement presentment system which allows billers 
and other entities to efficiently and cost effectively deliver electronic statements to respective 
consumers of their services and products (Column 4, lines 11-16). 

The Applicable Legal Standards 

Before a claim may be rejected on the basis of obviousness pursuant to 35 U.S.C. § 103, 
the Patent Office bears the burden of establishing that all the recited features of the claim are 
known in the prior art. This is known as prima facie obviousness. To establish prima facie 
obviousness, it must be shown that all the elements and relationships recited in the claim are 
known in the prior art. If the Office does not produce a prima facie case, then the Appellants are 
under no obligation to submit evidence of nonobviousness. MPEP § 2142. 

The teaching, suggestion, or motivation to combine the features in prior art references 
must be clearly and particularly identified in such prior art to support a rejection on the basis of 
obviousness. It is not sufficient to offer a broad range of sources and make conclusory 
statements. In re Dembiczak, 175 F.3d 994, 999, 50 USPQ2d 1614, 1617 (Fed. Cir. 1999). 

Even if all of the features recited in the claim are known in the prior art, it is still not 
proper to reject a claim on the basis of obviousness unless there is a specific teaching, 
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suggestion, or motivation in the prior art to produce the claimed combination. Panduit Corp. v. 
Dennison Mfg. Co., 810 F.2d 1561, 1568, 1 USPQ2d 1593 (Fed. Cir. 1987). In re Newell 891 
F.2d 899, 901, 902, 13 USPQ2d 1248, 1250 (Fed. Cir. 1989). 

The evidence of record must teach or suggest the recited features. An assertion of basic 
knowledge and common sense not based on any evidence in the record lacks substantial evidence 
support. In re Zurko, 258 F.3d 1379, 59 USPQ2d 1693 (Fed. Cir. 2001). 

A determination of patentability must be based on evidence of record. In re Lee, 277 
F.3d 1338, 61 USPQ2d 1430 (Fed. Cir. 2002). 

It is respectfully submitted that the Action from which this appeal is taken does not meet 
these burdens. 

The 35 U.S.C. § 103 (a) Rejections 

Rejection under 35 U.S.C. § 103(a) over Reisman in view of Rolling 

Claims 1-32 were rejected under 35 U.S.C. § 103(a) as being unpatentable over Reisman 
in view of Kolling. These rejections are respectfully traversed. 

Portions of Koliing relied on to support rejections are not prior art 

The present application is a continuation-in-part of Application Serial No. 09/193,787 
filed November 17, 1998 and claims the benefit of Provisional Application Serial No. 
60/149,765 filed August 19, 1999. Further, Application Serial No. 09/193,787 is a continuation- 
in-part of Application Serial No. 09/077,337 filed as PCT/US97/21422 on November 25, 1997 
and claims the benefit of Provisional Application Serial Nos. 60/031,956 filed November 27, 
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1996; 60/091,887 filed July 7, 1998; 60/095,626 filed August 7, 1998; and 60/098,907 filed 
September 2, 1998. 

Kolling is a continuation of Application Serial No. 08/947,629 (now U.S. Patent No. 
5,963,925) which claims the benefit of U.S. Provisional Application Serial No. 60/028,095 filed 
October 9, 1996. A copy of Rolling's Provisional Application No. 60/028,095 filed October 9, 
1996 and Appellants' earliest provisional Application No, 60/031,956 filed November 27, 1996 
are attached herewith in the Evidence Appendix. 

Although Appellants' earliest provisional application (60/031,956 filed November 27, 
1996) was filed later than Rolling's provisional application (60/028,095 filed October 9, 1996), 
portions of Kolling cited in the Action for supporting the rejection of the claims are not present 
in Rolling's provisional application. In addition, in the "Response to Arguments and 
Amendments" section of the Action (Page 2), the Office acknowledges that a detailed one to one 
mapping of each element of Rolling's provisional to the subsequent Rolling application cannot 
be made. 

Thus, portions of Rolling relied on in the Action to support the rejection of claims 1-32 do not 
qualify as prior art for purposes of rejecting the claims under 35 U.S.C. § 103(a). 

For example, the Action cited Column 15, lines 32-41 of Rolling with respect to steps (a) 
and (b) of claim 1. Column 15, lines 32-41 of Rolling is a discussion of a field (320) containing 
a bank identifier (BIN) and other fields shown in Figure 4. Figure 4 of Rolling is directed to a 
Universal Biller File (UBF). However, Figure 4 of Rolling's Provisional Application 60/028,095 
(enclosed herewith) does not teach or suggest a UBF or any of the fields described in Column 15, 
lines 32-41 of Rolling. Rather, Figure 4 of Rolling's provisional application only shows a block 
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diagram illustrating a transaction. Further, there is no corresponding figure or discussion 
anywhere in Rolling's provisional application which corresponds to Column 15, lines 32-41 of 
Rolling. 

In addition, the Action cited Figure 3 and reference numerals 216 and 300 of Figure 3 of 
Rolling with respect to step (b) of Appellants' claim 8. However, Figure 3 of Rolling's 
provisional application does not correspond to Figure 3 of Rolling. Further, there is no 
corresponding figure anywhere in Rolling's provisional application which includes reference 
numerals 216 and 300. 

In contrast, Appellants' earliest provisional application no. 60/031,956 filed November 
27, 1996 (enclosed herewith), fully supports Appellants' independent claims. For example, 
claim 1 recites: a) determining through operation of an automated banking machine, data 
corresponding to an entity with which a customer operating the machine has an account; and b) 
providing through an output device on the automated banking machine at least one output 
uniquely corresponding to the entity with which the customer has the account. . 

Support for the subject matter of claim 1 is found in Appellants' earliest provisional 
application, such as at page 7, lines 1-18. Further examples of the subject matter recited in at 
least Appellants' independent claims is shown at page 18, line 3 to page 22, line 19 of 
Appellants' earliest provisional application. 

Appellants' independent claims are fully supported by Appellants' earliest provisional 
application while Rolling's provisional does not support the features relied on in the Action to 
reject the claims. Thus the portions of Rolling relied on in the Action do not qualify as prior art 
and cannot be used as a basis for a rejection of the claims under 35 U.S.C. § 103. 



-15- 



Claim 1 

As discussed previously, the Action has failed to show that all of the portions of Kolling 
relied upon in the Action to support the rejection of claim 1 qualify as prior art under 35 U.S.C. § 
103. 

In addition, even if all portions of Kolling qualified as prior art (which they do not), 
Appellants respectfully submit that Reisman and Kolling still do not disclose or suggest each and 
every element, relationship and step of the claimed invention arranged in the manner recited in 
claim 1, as is required to sustain the rejection. 

For example, Reisman does not disclose or suggest an automated banking machine. As 
discussed previously, the term "ATM" used in Reisman is an acronym for "asynchronous transfer 
mode," which does not correspond to or suggest to one skilled in the art an automated banking 
machine such as an automated teller machine (also acronym "ATM"). 

Thus the primary reference of Reisman upon which the rejection of claim 1 is based does 
not disclose or suggest from step (a): "determining through operation of an automated banking 
machine" as alleged in the Action. Further, the Action admits that Reisman does not disclose the 
remainder of step (a): "data corresponding to an entity with which a customer operating the 
machine has an account." Consequently, Reisman does not disclose or suggest step (a) of claim 
1. Further the Reisman does not disclose or suggest step (b) of claim 1 as well. 

To overcome the admitted deficiencies of Reisman, the Action asserts that at least 
portions of step (a) and all of steps (c) and (d) are found in Kolling. Appellants disagree. 
The Action cites column 15, lines 32-41 and column 34, lines 5-17 of Kolling with respect to 
claim 1. Column 15, lines 32-41 of Kolling states: 
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Field 320 contains a bank identifier number (BIN) that identifies the 
biller's bank. The BIN may be in any suitable format. By way of 
example, BIN 322 is a six-digit number that uniquely identifies the bank 
used by the biller. Field 324 contains the biller's bank descriptive data. 
This descriptive data contains information such as bank name, address, 
telephone numbers, mailing information, and other descriptive 
information. For example, field 324 contains name and address 
information 326 for the Acme Financial Bank. 
Column 34, lines 5-17 of Kolling states: 

CPU 982 is also coupled to an interface 990 that includes one or more 
input/output devices such as such as video monitors, track balls, mice, 
keyboards, microphones, touch sensitive displays, transducer card readers, 
magnetic or paper tape readers, tablets, styluses, voice or handwriting 
recognizers, biometrics readers, or other computers. CPU 982 optionally 
may be coupled to another computer or telecommunications network using 
a network connection as shown generally at 992. With such network 
connection, it is contemplated that the CPU might receive information 
from the network, or might output information to the network in the course 
of performing the above-described method steps. 

However, neither of these portions of Kolling (nor any other portion of Kolling) teaches 
or suggests all of the elements, relationships or steps recited in claim 1 . For example, where do 
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these portions or any other portion of Rolling disclose "determining through operation of an 
automated banking machine?" Nowhere in Rolling is it suggested that the CPU 982 or any other 
component of Rolling corresponds to an automated banking machine. 

As discussed in Appellants' Specification (page 1, lines 7-18), an example of an 
automated banking machine includes an automated teller machine ("ATM"). ATMs enable 
customers to carry out banking transactions including transfers of value. Rolling does not 
disclose or suggest that any portion of the described electronic statement presentment system 
includes the operation of an automated banking machine or ATM. 

Nowhere does Rolling disclose or suggest step (a) of: "determining through operation of 
an automated banking machine, data corresponding to an entity with which a customer operating 
the machine has an account." Column 15, lines 32-41 of Rolling discusses fields or data 
associated with a Universal Biller File (UBF). However, Rolling does not disclose or suggest 
that such data is determined through operation of an automated banking machine. Nor does 
Rolling disclose or suggest such data corresponds to an entity with which a customer operating 
an automated banking machine has an account. Thus, neither Reisman nor Rolling discloses or 
suggests step (a) of claim 1 . 

In addition with respect to step (b), where does Rolling disclose or suggest "providing 
through an output device on the automated banking machine at least one output uniquely 
corresponding to the entity with which the customer has the account?" Neither the referenced 
portions of Rolling nor any other portion of Rolling discloses providing such outputs through an 
automated banking machine. Further, Reisman does not disclose or suggest this step which is 
missing from Rolling. 



Appellants respectfully submit that the Office has not established prima facie 
obviousness. Reisman and Rolling do not disclose or suggest each and every element, 
relationship and step of the claimed invention arranged in the manner recited in the claim, as is 
required to sustain the rejection. Nor has the Office cited any other prior art which shows the 
features and relationships missing from Reisman and Rolling. Nor is there any prior art teaching, 
suggestion, or motivation cited for modifying Reisman in view of Rolling so as to produce the 
claimed invention. Further, it would not have been obvious to one having ordinary skill in the art 
to have modified Reisman in view of Rolling to have produced the claimed invention. 
Appellants respectfully submit that the 35 U.S.C. § 103(a) rejection is improper and should be 
withdrawn. 

Claim 2 

Claim 2 depends from claim 1. Although Rolling lists input devices capable of being 
connected to a CPU (Column 34, lines 6-10), Rolling (as well as Reisman) fails to disclose or 
suggest reading indicia with a reading device in operative connection with an automated banking 
machine. Thus, the Office has not established prima facie obviousness with respect to claim 2. 

Claim 3 

Claim 3 depends from claim 2. Although Rolling lists "transducer card readers" among 
numerous input/output devices capable of being connected to a CPU (Column 34, line 8), 
Rolling (as well as Reisman) fails to disclose or suggest reading indicia on a card with a card 
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reader in connection with the automated banking machine. Thus, the Office has not established 
prima facie obviousness with respect to claim 3. 

Claim 4 

Claim 4 depends from claim 1. Although Rolling lists output devices capable of being 
connected to a CPU (Column 34, lines 6-10), Rolling (as well as Reisman) fails to disclose or 
suggest providing at least one visual output corresponding to the entity through the output device 
on an automated banking machine. Thus, the Office has not established prima facie obviousness 
with respect to claim 4. 

Claim 5 

Claim 5 depends from claim 1. Although Rolling shows a browser in Figure 11, Rolling 
(as well as Reisman) fails to disclose or suggest processing at least one document through a 
browser operating in a computer in operative connection with an automated banking machine. 
Thus, the Office has not established prima facie obviousness with respect to claim 5. 

Claim 6 

Claim 6 depends from claim 5. Neither Reisman nor Rolling discloses or suggests a 
document processed through a browser which is determined responsive to data determined 
through operation of an automated banking machine. Thus, the Office has not established prima 
facie obviousness with respect to claim 6. 
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Claim 7 

Claim 7 depends from claim 6. Neither Reisman nor Rolling discloses or suggests 
accessing a document processed through a browser at a system address, which address is 
determined responsive to data determined through operation of an automated banking machine. 
Thus, the Office has not established prima facie obviousness with respect to claim 7. 

Claim 8 

As discussed previously, the Action has failed to show that all of the portions of Rolling 
relied upon in the Action to support the rejection of claim 8 qualify as prior art under 35 U.S.C. § 
103. 

In addition, even if all portions of Rolling qualified as prior art (which they do not), 
Appellants respectfully submit that Reisman and Rolling still do not disclose or suggests each 
and every element, relationship and step of the claimed invention arranged in the manner recited 
in claim 8, as is required to sustain the rejection. 

For example, Reisman does not disclose or suggest an automated banking machine. As 
discussed previously, the term "ATM" used in Reisman is an acronym for "asynchronous transfer 
mode," which does not correspond to or suggest to one skilled in the art an automated banking 
machine such as an automated teller machine (also acronym "ATM"). 

Thus the primary reference of Reisman upon which the rejection of claim 8 is based does 
not disclose or suggest an automated banking machine such as an ATM as alleged in the Action. 
Further, the Action admits that Reisman does not disclose or suggest any portion of step (a) 
which recites: "reading card indicia on a card presented by a customer to an automated banking 
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machine, the card indicia including entity data corresponding to an entity with which the 
customer has an account." Further Reisman does not disclose or suggest steps (b) and (c) of 
claim 8 as well. 

To overcome the admitted deficiencies of Reisman, the Action asserts that at least 
portions of step (a) and all of steps (b) and (c) are found in Rolling. Appellants disagree. 
Neither the portions of Rolling (Column 15, lines 32-41; Column 34, lines 5-17) asserted in the 
Action of showing step (a) nor any other portion of Rolling, discloses or suggests reading card 
indicia on a card presented by a customer to an automated banking machine, or that the card 
indicia includes entity data corresponding to an entity with which the customer has an account. 

With respect to step (b) the Action cites Figure 3 of Rolling and reference numerals 216 
and 300. Figure 3 of Rolling corresponds to an electronic statement presentment (ESP) System. 
Reference number 216 of Rolling corresponds to a template library. Reference number 300 of 
Rolling corresponds to the previously described universal biller file (UBF). 

However, neither Figure 3, reference numerals 216 and 300, nor any other portion of 
Rolling discloses or suggests an automated banking machine. In addition, Rolling does not 
disclose or suggest, as recited in step (b), resolving network address data with an automated 
banking machine responsive to entity data and data stored in a data store. Further, Rolling does 
not disclose or suggest that the entity data used to resolve the network address with an automated 
banking machine was read from a card presented by a customer to the automated banking 
machine. 

In addition, with respect to step (c), Rolling does not disclose or suggest operating a 
browser in an automated banking machine. Further, Rolling does not disclose or suggest 
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operating the browser responsive to network address data resolved by the automated banking 
machine, responsive to entity data read from a card presented by a customer to the automated 
banking machine. Further Rolling does not disclose or suggest operating a browser in an 
automated banking machine to access at least one network address which corresponds to an 
address of a server adapted to deliver documents corresponding to the entity with which the 
customer has the account. 

Appellants respectfully submit that the Office has not established prima facie 
obviousness. Reisman and Rolling do not disclose or suggest each and every element, 
relationship and step of the claimed invention arranged in the manner recited in the claim, as is 
required to sustain the rejection. Nor has the Office cited any other prior art which shows the 
features and relationships missing from Reisman and Rolling. Nor is there any prior art teaching, 
suggestion, or motivation cited for modifying Reisman in view of Rolling so as to produce the 
claimed invention. Further, it would not have been obvious to one having ordinary skill in the art 
to have modified Reisman in view of Rolling to have produced the claimed invention. 
Appellants respectfully submit that the 35 U.S.C. § 103(a) rejection is improper and should be 
withdrawn. 

Claim 9 

Claim 9 depends from claim 5. Neither Reisman nor Rolling discloses or suggests 
processing at least one document corresponding to the entity with which the customer has the 
account, from the server, and providing at least one output through an output device of an 
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automated banking machine responsive to the at least one document. Thus, the Office has not 
established prima facie obviousness with respect to claim 9. 

Claim 10 

Claim 10 depends from claim 9. Neither Reisman nor Rolling discloses or suggests 
providing at least one visual output through a display of an automated banking machine 
responsive to a document corresponding to an entity with which the customer has an account. 
Thus, the Office has not established prima facie obviousness with respect to claim 10. 

Claim 11 

Claim 1 1 depends from claim 8. The Action lists Figure 2 of Rolling and reference 
numeral 120 as being relevant to the features recited in claim 1 1 . Figure 2 is directed to an 
electronic statement presentment environment. Reference numeral 120 corresponds to a 
coordinating entity. However, neither this portion of Rolling, nor any other portion of Rolling or 
Reisman, discloses or suggests a first document including an instruction which is operative to 
cause operation of the transaction function device of an automated banking machine. Further, 
neither Reisman nor Rolling discloses or suggests processing the first document with a browser 
in the automated banking machine and operating the transaction function device responsive to the 
at least one instruction in the first document. Thus, the Office has not established prima facie 
obviousness with respect to claim 1 1 . 
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Claim 12 

Claim 12 depends from claim 8. Although Rolling discloses a system which may include 
multiple entities such as a biller (104), a biller service provider (106), and a biller financial 
institution (108) (Figure 2; column 7, lines 30-38), neither Reisman nor Rolling discloses or 
suggests providing a plurality of servers, one for each of a plurality of entities with which a 
plurality of users of the automated banking machine have accounts. Further, neither Reisman nor 
Kolling discloses or suggests repeating steps (a) through (c) for each card presented by a 
customer at the automated banking machine. In addition, neither reference discloses or suggests 
that each customer card is operative to cause the browser in the automated banking machine to 
connect to the server including the at least one document corresponding to the entity with which 
the customer has their account. Thus, the Office has not established prima facie obviousness 
with respect to claim 12. 

Claim 13 

Claim 13 depends from claim 12. Neither Reisman nor Kolling discloses or suggests that 
an automated banking machine includes a display in operative connection with a browser. In 
addition, neither reference discloses or suggests that the browser is operative responsive to the 
instructions in the documents to cause to be produced on the display of the automated banking 
machine the at least one screen uniquely associated with the entity with which the customer has 
their account. Thus, the Office has not established prima facie obviousness with respect to claim 
13. 
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Claim 14 

Claim 14 depends from claim 8. The Action asserts that Column 1, lines 30-47 of 
Rolling is relevant to claim 14. However, this portion of Rolling discusses costs associated with 
processing a submitted remittance for a bill. Neither this portion of Rolling nor any other portion 
of Rolling or Reisman discloses or suggests charging the account of the customer a transaction 
fee for use of the automated banking machine operated by the further entity. In addition, neither 
reference discloses or suggests sharing between the entity and the further entity at least a portion 
of the transaction fee. Thus, the Office has not established prima facie obviousness with respect 
to claim 14. 

Claim 15 

Claim 15 depends from claim 8. With respect to step (d), neither Reisman nor Rolling 
discloses or suggests accessing with a browser of an automated banking machine a plurality of 
documents from the server associated with the entity with which the customer has the account. 

With respect to step (e) although Rolling discusses advertising biller availability in 
providing electronic statements to consumers (Column 26, lines 30-50; column 27, lines 12-20), 
neither Reisman nor Rolling discloses or suggests accessing with a browser operating in the 
automated banking machine, at least one advertising document from a further server operated by 
an advertising entity. Further, neither reference discloses or suggests processing the advertising 
document with a browser to produce advertising content through an output device in operative 
connection with the automated banking machine. Thus, the Office has not established prima 
facie obviousness with respect to claim 15. 
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Claim 16 

Claim 16 depends from claim 15. Neither Reisman nor Rolling discloses or suggests 
making a payment by the advertising entity to the further entity, whereby the further entity 
operating the automated banking machine is compensated for having the advertising entity 
present advertising content on the banking machine. Thus, the Office has not established prima 
facie obviousness with respect to claim 16. 

Claim 17 

Claim 17 depends from claim 15. Neither Reisman nor Kolling discloses or suggests 
executing a step of accessing with a browser operating in the automated banking machine at least 
one advertising document from a further server operated by an advertising entity during a step of 
accessing with a browser a plurality of documents from the server associated with the entity with 
which the customer has the account. Thus, the Office has not established prima facie 
obviousness with respect to claim 17. 

Claim 18 

Claim 18 depends from claim 15. Neither Reisman nor Kolling discloses or suggests 
accessing at least one document with a first browser operating in an automated banking machine, 
and accessing at least one document with a second browser operating in the automated banking 
machine. Thus, the Office has not established prima facie obviousness with respect to claim 18. 
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Claim 19 

As discussed previously the Action has failed to show that all of the portions of Kolling 
relied upon in the Action to support the rejection of claim 19 qualify as prior art under 35 U.S.C. 
§ 103. 

In addition, even if all portions of Kolling qualified as prior art (which they do not), 
Appellants respectfully submit that Reisman and Kolling still do not disclose or suggests each 
and every element, relationship and step of the claimed invention arranged in the manner recited 
in claim 19, as is required to sustain the rejection. 

For example, Reisman does not disclose or suggest an automated banking machine. As 
discussed previously, the term "ATM" used in Reisman is an acronym for "asynchronous transfer 
mode," which does not.correspond to or suggest to one skilled in the art an automated banking 
machine such as an automated teller machine (also acronym "ATM"). 

Thus the primary reference of Reisman upon which the rejection of claim 19 is based 
does not disclose or suggest an automated banking machine such as an ATM as alleged in the 
Action. Further the Action admits that Reisman does not disclose or suggest: a plurality of 
institution servers, each institution server associated with one of a plurality of financial 
institutions. In addition, the Action admits that Reisman does not disclose or suggest that each 
institution server has at least one unique network address and each institution server is operative 
to deliver at least one document associated with the respective institution. Further the Action 
does not show where Reisman discloses or suggests any other element or relationship recited in 
claim 19. 
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To overcome the admitted deficiencies of Reisman, the Action asserts that Rolling 
discloses these features which are missing from Reisman. Appellants disagree. As discussed 
previously, Rolling does not disclose or suggest an automated banking machine. Further, 
Rolling does not disclose or suggest an automated banking machine which includes a computer 
having a browser operating therein. In addition, Rolling does not disclose or suggest an 
automated banking machine that is operative responsive to reading card indicia on a card read by 
the card reading device of the machine to cause the browser to connect through a network to a 
network address of an institution server corresponding to the card indicia. 

Appellants respectfully submit that the Office has not established prima facie 
obviousness. Reisman and Rolling do not disclose or suggest each and every element, 
relationship and step of the claimed invention arranged in the manner recited in the claim, as is 
required to sustain the rejection. Nor has the Office cited any other prior art which shows the 
features and relationships missing from Reisman and Rolling. Nor is there any prior art teaching, 
suggestion, or motivation cited for modifying Reisman in view of Rolling so as to produce the 
claimed invention. Further, it would not have been obvious to one having ordinary skill in the art 
to have modified Reisman in view of Rolling to have produced the claimed invention. 
Appellants respectfully submit that the 35 U.S.C. § 103(a) rejection is improper and should be 
withdrawn. 
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Claim 20 

Claim 20 depends from claim 19. Neither Reisman nor Kolling discloses or suggests a 
browser operative to process at least one document from an institution server and to provide an 
output responsive to the document through an output device on an automated banking machine. 
Thus, the Office has not established prima facie obviousness with respect to claim 20. 

Claim 21 

Claim 21 depends from claim 19. Neither Reisman nor Kolling discloses or suggests a 
browser in an automated banking machine is operative to process at least one document from an 
institution server. In addition neither reference discloses or suggests that the document processed 
by the browser in the automated banking machine includes at least one instruction for enabling 
operation of a transaction function device included in the automated banking machine. Further 
neither reference discloses or suggests that the transaction function device is enabled to operate 
responsive to the browser processing the document. Thus, the Office has not established prima 
facie obviousness with respect to claim 21. 

Claim 22 

Claim 22 depends fr om claim 21. Neither Reisman nor Kolling discloses or suggests a 
document processed by a browser in an automated banking machine which includes at least one 
sheet dispenser instruction. In addition, neither reference discloses or suggests a sheet dispenser 
in an automated banking machine which is enabled to dispense at least one sheet responsive to 
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the browser processing the document. Thus, the Office has not established prima facie 
obviousness with respect to claim 22. 

Claim 23 

Claim 23 depends from claim 19. Neither Reisman nor Rolling discloses or suggests an 
automated banking machine which is operative to resolve a network address responsive to a BIN 
number included in card indicia read from a card. Thus, the Office has not established prima 
facie obviousness with respect to claim 23. 

Claim 24 

Claim 24 depends from claim 19. Neither Reisman nor Rolling discloses or suggests a 
computer in an automated banking machine which is programmed to operate to cause a browser 
to access an advertising document from an advertising server. In addition, neither reference 
discloses or suggests that the computer of the automated banking machine is operative to output 
advertising content through the output device of the automated banking machine responsive to 
the advertising document. Thus, the Office has not established prima facie obviousness with 
respect to claim 24. 

Claim 25 

Claim 25 depends from claim 24. Neither Reisman nor Rolling discloses or suggests 
a computer in an automated banking machine which is operative to cause a browser to process at 
least one document from an institution server, which document includes device instructions. In 
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addition, neither reference discloses or suggests that a computer in the automated banking 
machine is adapted to enable a transaction function device of the automated banking machine to 
operate responsive to the device instructions. Further, neither reference discloses or suggests a 
computer in an automated banking machine which operates to cause advertising content to be 
output through an output device during operation of the transaction function device. Thus, the 
Office has not established prima facie obviousness with respect to claim 25. 

Claim 26 

Claim 26 depends from claim 25. Neither Reisrhan nor Rolling discloses an automated 
banking machine with a note dispenser. In addition, neither reference discloses or suggests a 
computer in an automated banking machine which is adapted to enable a note dispenser of the 
automated banking machine to operate responsive to the device instructions. Further, neither 
reference discloses or suggests a computer in an automated banking machine which operates to 
cause advertising content to be output through an output device during operation of the note 
dispenser. Thus, the Office has not established prima facie obviousness with respect to claim 26. 

Claim 27 

Claim 27 depends from claim 24. Neither Reisman nor Rolling discloses or suggests a 
computer in an automated banking machine which includes a first browser and a second browser 
operating therein. Further, neither reference discloses or suggests that the computer in the 
automated banking machine operates the first browser to access an institution server and the 
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second browser to access an advertising server. Thus, the Office has not established prima facie 
obviousness with respect to claim 27. 

Claim 28 

Claim 28 depends from claim 1. Neither Reisman nor Rolling discloses or suggests an 
automated banking machine which includes a cash dispenser. Thus, the Office has not 
established prima facie obviousness with respect to claim 28. 

Claim 29 

Claim 29 depends from claim 28. Neither Reisman nor Rolling discloses or suggests 
dispensing cash through operation of a cash dispenser. Thus, the Office has not established 
prima facie obviousness with respect to claim 29. 

Claim 30 

Claim 30 depends from claim 8, Neither Reisman nor Rolling discloses or suggests an 
automated banking machine which includes a cash dispenser. Thus, the Office has not 
established prima facie obviousness with respect to claim 30. 

Claim 31 

Claim 31 depends from claim 30. Neither Reisman nor Rolling discloses or suggests 
dispensing cash through operation of a cash dispenser. Thus, the Office has not established 
prima facie obviousness with respect to claim 31. 
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Claim 32 

Claim 32 depends from claim 19. Neither Reisman nor Rolling discloses or suggests an 
automated banking machine which comprises a cash dispenser. Thus, the Office has not 
established prima facie obviousness with respect to claim 32. 

CONCLUSION 

Each of Appellants' pending claims specifically recites elements, relationships, and steps 
that are neither disclosed nor suggested in any of the applied prior art. Furthermore, the applied 
prior art is devoid of any teaching, suggestion, or motivation for producing the recited invention. 
For these reasons it is respectfully submitted that all the pending claims are allowable. 

Respectfully submitted, 



Ralph E. Jotkt Reg. No. 3 1 ,029 

WALKER^ JOCKE 
231 South Broadway 
Medina, Ohio 44256 
(330) 721-0000 
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(viii) CLAIMS APPENDIX 

1 . A method comprising the steps of: 

a) determining through operation of an automated banking machine, data 
corresponding to an entity with which a customer operating the machine 
has an account; 

b) providing through an output device on the automated banking machine at 
least one output uniquely corresponding to the entity with which the 
customer has the account. 

2. The method according to claim 1 wherein step (a) includes reading indicia with a 
reading device in operative connection with the banking machine. 

3. The method according to claim 2 wherein step (a) includes reading indicia on a 
card with a card reader in connection with the automated banking machine. 

4. The method according to claim 1 wherein step (b) includes providing at least one 
visual output corresponding to the entity through the output device. 
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5. The method according to claim 4 wherein step (b) includes processing at least one 
document through a browser operating in a computer in operative connection with an automated 
banking machine. 

6. The method according to claim 5 wherein in step (b) the at least one document is 
determined responsive to the data determined in step (a). 

7. The method according to claim 6 and prior to step (b) further comprising the step 

of: 

accessing the at least one document at a system address, wherein the system 
address is determined responsive to the data determined in step (a). 

8. A method comprising the steps of: 

a) reading card indicia on a card presented by a customer to an automated 
banking machine, the card indicia including entity data corresponding to 
an entity with which the customer has an account; 

b) resolving network address data with the banking machine responsive to the 
entity data and data stored in a data store; 
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c) operating a browser in the banking machine responsive to the resolved 

network address data, to access at least one network address in a network, 
wherein the network address accessed corresponds to an address of a 
server adapted to deliver documents corresponding to the entity with 
which the customer has the account. 

9. The method according to claim 8 wherein the banking machine includes an output 
device, and further comprising the steps of processing at least one document corresponding to the 
entity with which the customer has the account from the server, and providing at least one output 
through the output device responsive to the at least one document. 

10. The method according to claim 9 wherein the output device comprises a display, 
and wherein in the providing step the output includes a visual output. 

1 1 . The method according to claim 8 wherein the automated banking machine 
includes at least one transaction function device, and wherein at least a first one of the documents 
includes at least one instruction which is operative to cause operation of the transaction function 
device, and farther comprising the step of processing the first document with the browser and 
operating the transaction function device responsive to the at least one instruction in the first 
document. 

12. The method according to claim 8 and further comprising the steps of: 
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d) providing a plurality of servers, one for each of a plurality of entities with 
which a plurality of users of the automated banking machine have 
accounts, each server being in operative connection with a network and 
having a corresponding network address, each server being adapted to 
deliver at least one document corresponding to the entity with which it is 
associated; 

repeating steps (a) through (c) for each card presented by a customer at the 
automated banking machine, whereby each customer card is operative to cause the 
browser to connect to the server including the at least one document 
corresponding to the entity with which the customer has their account. 



13. The method according to claim 12 wherein the automated banking machine 
includes a display in operative connection with the browser, and wherein the documents include 
instructions for producing at least one screen uniquely associated with the corresponding entity, 
and wherein in step (c) the browser is operative responsive to the instructions in the documents to 
cause to be produced on the display the at least one screen uniquely associated with the entity 
with which the customer has their account. 



14. The method according to claim 8 wherein the automated banking machine is 
operated by a further entity, and further comprising the steps of: 
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d) charging the account of the customer a transaction fee for use of the 
automated banking machine operated by the further entity; 

e) sharing between the entity and the further entity at least a portion of the 
transaction fee. 

15. The method according to claim 8 and further comprising the step of: 

d) accessing with a browser a plurality of documents from the server 
associated with the entity with which the customer has the account; 

e) accessing with a browser operating in the automated banking machine at 
least one advertising document from a further server operated by an 
advertising entity; 

f) processing the advertising document with a browser to produce advertising 
content through an output device in operative connection with the 
automated banking machine. 

16. The method according to claim 15 wherein the automated banking machine is 
operated by a further entity, and further comprising the step of: 
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g) making a payment by the advertising entity to the further entity, whereby 
the further entity operating the automated banking machine is 
compensated for having the advertising entity present advertising content 
on the banking machine. 

17. The method according to claim 15 wherein step (e) is executed during step (d). 

18. The method according to claim 15 wherein in step (d) at least one document is 
accessed with a first browser operating in the banking machine, and wherein in step (e) at least 
one document is accessed with a second browser operating in the banking machine. 

19. An apparatus comprising: 

a plurality of institution servers, each institution server associated with one of a 
plurality of financial institutions, wherein each institution server has at least one 
unique network address, and wherein each institution server is operative to deliver 
at least one document associated with the respective institution; 

a network in operative connection with each of the plurality of institution servers; 
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at least one automated banking machine, wherein the banking machine includes a 
computer having a browser operating therein, a card reader and an output device 
in operative connection with the computer; 

wherein the automated banking machine is operative responsive to reading card 
indicia on a card read by the card reading device, to cause the browser to connect 
through the network to a network address of an institution server corresponding to 
the card indicia. 

20. The apparatus according to claim 19 wherein the browser is operative to process 
at least one document from the institution server and to provide an output responsive to the 
document through the output device on the banking machine. 

21. The apparatus according to claim 19 wherein the browser is operative to process 
at least one document from the institution server, wherein the banking machine includes at least 
one transaction function device, and wherein the document includes at least one instruction for 
enabling operation of the transaction function device, and wherein the transaction function device 
is enabled to operate responsive to the browser processing the document. 

22. The apparatus according to claim 21 wherein the transaction function device 
includes a sheet dispenser, and wherein the document includes at least one sheet dispenser 
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instruction, and wherein the sheet dispenser is enabled to dispense at least one sheet responsive 
to the browser processing the document. 

23. The apparatus according to claim 19 wherein the card indicia includes a BIN 
number, and wherein the automated banking machine is operative to resolve the network address 
responsive to the BIN number. ; 

24. The apparatus according to claim 19 and further comprising at least one 
advertising server in operative connection with the network, wherein the advertising server has at 
least one unique network address, and wherein the advertising server is operative to provide at 
least one advertising document, and wherein the computer is programmed to operate to cause the 
browser to access the advertising document from the advertising server, wherein the computer is 
operative to output advertising content through the output device responsive to the advertising 
document. 

25. The apparatus according to claim 24 wherein the automated banking machine 
includes at least one transaction function device in operative connection with the computer, and 
wherein the computer is operative to cause the browser to process at least one document from the 
institution server, and wherein the document from the institution server includes device 
instructions, and wherein the computer is adapted to enable the transaction function device to 
operate responsive to the device instructions, and wherein the computer operates to cause the 
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advertising content to be output through the output device during operation of the transaction 
function device. 

26. The apparatus according to claim 25 wherein the transaction function device 
includes a note dispenser, and wherein the advertising content is output during operation of the 
note dispenser. 

27. The apparatus according to claim 24 wherein the computer includes a first 
browser and a second browser operating therein, and wherein the computer operates the first 
browser to access the institution server and the second browser to access the advertising server. 

28. The method according to claim 1, wherein in (a) the automated banking machine 
includes a cash dispenser. 

29. The method according to claim 28, further comprising: 

d) dispensing cash through operation of the cash dispenser. 

30. The method according to claim 8, wherein in (a) the automated banking machine 
includes a cash dispenser. 
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3 1 . The method according to claim 30, further comprising: 

d) dispensing cash through operation of the cash dispenser. 

32. The apparatus according to claim 19, wherein the automated banking machine 
comprises a cash dispenser. 
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TECHNICAL FIELD 
This invention relates to automated banking machines. Specifically this invention 
relates to an automated banking machine apparatus and system that is capable of use in a 
wide area network, and which provides a user with a familiar interface from their home 
institution at banking machines operated by other institutions. 

BACKGROUND ART 

Automated banking machines are well known. A common type of automated banking 
machine used by consumers is an automated teller machine ("ATM"). ATMs enable 
customers to carry out banking transactions. Common banking transactions carried out with 
ATMs include the dispensing of cash, the making of deposits, the transfer of funds between 
accounts, the payment of bills and account balance inquiries. The type of banking 
transactions a customer can carry out are determined by capabilities of the particular banking 
machine and the programming of the institution operating the machine. 

Currently ATMs are operated in proprietary communications networks. These 
networks interconnect ATMs operated by financial institutions and other entities. The 
interconnection of the networks often enables a user to use a banking machine operated by 
another institution if the foreign institution's banking machine is interconnected with the 
network that includes the user's institution. However when the customer operates the foreign 
institution's machine the customer must operate the machine using the customer interface that 
has been established by the foreign institution for its banking machines. In addition the user 
is limited to the transaction options provided by the foreign institution. 
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A customer may encounter difficulties when using a foreign institution's machine. 
Problems may occur because the user is not familiar with the type of machine operated by 
the foreign institution. Confusion may result because the customer does not know which 
buttons or other mechanisms to actuate to accomplish the desired transactions. The 
5 transaction flow for a customer at a foreign institution machine may be significantly different 
from machines operated by the user's home institution. This may be particularly a problem 
when the user is from another country and is not familiar with the type of banking machine 
or the language of the interface provided by the foreign institution. 

A foreign institution may also provide different types of transactions than the user is 

10 familiar with at their home institution. For example the user's home institution may enable 
the transfer of funds between accounts through their automated banking machines, to enable 
the user to maintain funds in higher interest bearing accounts until they are needed. If the 
foreign institution does not provide this capability, the user will be unable to do this when 
operating the foreign machine. The inability of a user at a foreign machine to conduct the 

15 transactions that they are accustomed to may present problems. 

The networks that operate automated teller machines and other types of automated 
banking machines generally operate proprietary networks to which access is restricted. This 
is necessary to prevent fraud or tampering with the network or user's accounts. Proprietary 
networks are also generally used for the transmission of credit card messages and other 

20 financial transaction messages. Access to such credit card processing systems is also 
restricted primarily for purposes of maintaining security. 
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Communication over wide area networks enables messages to be communicated 
between distant locations. The best known wide area network is the Internet which can be 
used to provide communication between computers throughout the world. The Internet is not 
widely used for financial transaction messages because it is not a secure system. Messages 
5 intended for receipt at a particular computer address may be intercepted at other addresses 
without detection. Because the messages may be intercepted at locations that are distant in 
the world from the intended recipient, the potential for fraud and corruption is great. 

Companies are beginning to provide approaches for more secure transmission of 
messages on the Internet. Encryption techniques are also being applied to Internet messages. 
10 However the openness of the Internet has limited its usefulness for purposes of financial 

messages, particularly financial messages associated with the operation of automated banking 
machines. 

Thus there exists a need for an automated banking machine and system that can be 
used in a wide area network such as the Internet while providing a high level of security. 
15 There further exists a need for an automated banking machine and system which provides a 
user with the familiar interface and transaction options of their home institution when 
operating foreign institution machines. 

DISCLOSURE OF INVENTION 
It is an object of the present invention to provide an automated banking machine at 
20 which a user may conduct transactions. 
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It is a further object of the present invention to provide an automated banking . 
machine that may be operated through connection to a wide area network. 

It is a further object of the present invention to provide an automated banking 
machine and system that provides a user with a familiar interface and transaction options of 
5 their home institution at machines operated by foreign institutions. 

It is a further object of the present invention to provide an automated banking 
machine that communicates using HTML documents and TCP/IP messages. 

It is a further object of the present invention to provide an automated banking 
machine that enables the connection of the banking machine to a user's home institution 
10 through HTML documents and TCP/IP messages generated responsive to indicia on a card 
input by a user. 

It is a further object of the present invention to provide an automated banking 

machine and system that accomplishes transactions over a wide area network while 

maintaining a high level of security. 
15 It is a further object of the present invention to provide an automated banking 

machine and system that controls connection of the banking machine to foreign addresses 

through a proxy server. 

It is a further object of the present invention to provide an automated banking 

machine that limits the operation of devices in the machine through a local device server. 
20 It is a further object of the present invention to provide an automated banking 

machine and system that is operable through connection to the Internet. 
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Further objects of the present invention will be made apparent in the following Best 
Modes for Carrying Out Invention and the appended Claims. 

The foregoing objects are accomplished in a preferred embodiment of the invention by 
an automated banking machine that includes an output device such as a display screen, and 
5 an input device such as a touch screen or a keyboard. The banking machine further includes 
devices such as a dispenser mechanism for sheets of currency, a printer mechanism, a card 
reader/writer, a depository mechanism and other physical devices that are used by the 
machine to accomplish banking transactions. 

The banking machine further includes a computer. The computer is in operative 
10 connection with the output device and the input device, as well as with the sheet dispenser 
mechanism, card reader and other physical devices in the banking machine. The computer 
includes software programs that are executable therein. The software programs include an 
HTML document handling portion. The HTML document handling portion operates to send 
and receive HTML documents. The HTML document handling portion is preferably in 
15 connection with the output device to display screens including hypertext link indicators. The 
HTML document handling portion is also preferably in connection with the input device 
which enables user selection and the generation of response messages from the computer. 
The HTML document handling portion preferably operates in connection with a JAVA 
software environment and has the capability of executing instructions in JAVA script 
20 transmitted with HTML documents. 

The software in the computer further preferably includes a device application portion. 
The device application portion includes software that is operative to control the sheet 
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dispenser and other devices. In the preferred form of the invention the device application 
portion includes a plurality of JAVA applets for operating the devices in the machine. 

The computer in the automated banking machine further includes a device interfacing 
software portion. The device interfacing software portion operates to receive messages from 
5 the device application portion and to cause the devices to operate through appropriate 

hardware interfaces. In the preferred form of the automated banking machine, the HTML 
document handling portion, device application portion and device interfacing software portion 
each reside on the same computer and communicate at different IP ports. 

The automated banking machine of the invention preferably communicates using 

10 TCP/IP messages in an intranet which includes a plurality of such machines. The intranet is 
in turn connected to at least one computer which is operated by a home institution. The 
home institution is the entity that operates the banking machines. 

The computer of the home institution preferably includes a home HTTP server, a 
proxy server and a device server. The proxy server communicates through the intranet with 

15 the HTML document handling portion of the software in each of the banking machines. The 
proxy server is also connectable to a wide area network, such as the Internet, to which 
foreign servers are connected. The device server is operative to pass messages between the 
device application portion and the device interfacing software portion of the banking 
machines. The device server includes monitor software which monitors and selectively limits 

20 the use and operation of the devices in the banking machine. This provides a level of 
security. 
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The automated banking machine and system is operative to place a user in connection 
with the institution where they have their accounts; This can be either the home institution 
that operates the banking machine where the user is present, or a foreign institution which is 
connected to the wide area network. To operate the banking machine a user inputs an 
5 address, such as a URL address, through an address input device. The HTML document 

handling portion operates to connect the banking machine to the server corresponding to that 
address. This is preferably accomplished by the user having indicia representative of the 
address on a card that is read by the banking machine. 

The HTML document handling portion is responsive to the address on the card to 

10 connect through the proxy server to the user's institution. If the user's home institution 
address corresponds to the home server, the banking machine operates responsive to 
messages from the home server. If however the user's input address corresponds to an 
address of a foreign server, the proxy server is operative to communicate through the wide 
area network with the foreign server at the customer's home institution. If the customer 

15 causes the machine to connect a server operated by a foreign institution, the HTML 

documents sent from the foreign institution correspond to those normally provided by the 
foreign institution. As a result the customer is familiar with the interface produced by these 
documents and will be able to more readily operate the banking machine. 

The foreign server or home server operate the banking machine by sending HTML 

20 documents that include instructions for operating the devices in the banking machine. The 
instructions are transmitted from the HTML document handling portion to the device 
application portion of the software, which operates the devices in response to the 
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instructions. The instructions from the device application portion to the devices in the 
automated bankirig machine are passed through the device server of the home institution. 
This helps to maintain security. In addition, the proxy server includes screening software 
which l imi ts the foreign servers which may connect to and operate the banking machine. 
This is referred to as a "fire wall." 

BRIEF DESCRIPTION OF DRAWINGS 

Figure 1 is a schematic view of a network configuration including the automated 
banking machine apparatus and system of the present invention. 

Figure 2 is a schematic view of a preferred embodiment of an automated banking 
machine of the present invention. 

Figures 3 through 24 show schematic views of the automated banking machine, an 
intranet connecting the banking machine to a computer system of a home bank and a wide 
area network connecting the computer system of the home bank to a foreign bank. 

Figures 3 through 18 schematically represent steps in a transaction carried out at the 
banking machine with the computer system of the home bank. 

Figures 19 through 24 schematically represent steps in a transaction carried out at the 
banking machine with the computer system of the foreign bank. 

BEST MODES FOR CARRYING OUT INVENTION 
Referring now to the drawings and particularly to Figure 1, there is shown therein a 
network configuration schematically indicated 10, which includes the automated banking 
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machine apparatus and system of a preferred embodiment of the present invention. Network 
10 includes a plurality of automated banking machines 12 which in the preferred embodiment 
of the invention are ATMs. ATMs 12 are connected to a computer system of a home bank 
schematically indicated 14. Home bank computer system 14 is the computer system that is 
5 operated by the bank or other institution which has primary responsibility for the ATMs 12. 
Home bank computer system 14 is connected to the ATMs 12 through an intranet 16. 
Intranet 16 is preferably a local or proprietary network that provides communication between 
the computer system 14 and the banking machines 12 using messages in the transmission 
control protocol/internet protocol ("TCP/IP") format. 

10 The messages that are communicated through the intranet 16 are preferably TCP/IP 

messages and hypertext mark up language ("HTML") documents. In the preferred 
embodiment of the invention the HTML documents sent through intranet 16 include 
embedded object oriented programming instructions, preferably in the JAVA® format which 
has been developed by Sun Microsystems. The messages sent through intranet 16 may be 

15 sent in an encrypted or unencrypted form depending on the nature of the system and the 
security needs of the home bank. 

Home bank computer system 14 is also connectable as shown to a wide area network 
18. In the preferred embodiment of the invention the wide area network 18 is the Internet. 
In other embodiments of the invention, other wide area networks may be used. The wide 

20 area network preferably communicates messages in TCP/IP between numerous computer 
systems connected to the wide area network. These foreign computer systems are 
schematically represented by servers 20, 22, 24, 26 and 28. It should be understood that 
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servers 20 through 28 may be operated by or connected to other financial institutions 
throughout the world. Servers 20 through 28 preferably operate by communicating HTML 
documents. 

Figure 2 shows a schematic view of the ATM 12 used in connection with a preferred 
embodiment of the invention. ATM 12 includes a touch screen 30. Touch screen 30 
includes a display screen which serves as an output device for communication with a user of 
the machine. Touch screen 30, because it is a touch screen, also serves as an input device 
for receiving input instructions from a user. Touch screen 30 is connected through an 
interface 32 to a computer 34 which is preferably housed within the machine. 

Computer 34 is also in connection with a plurality of devices 36 which are included in 
ATM 12. Devices 36 include for example, a card reader/writer mechanism 38 and a 
keyboard 40. Devices 36 further include a sheet dispenser mechanism 42 which is operative 
to dispense sheets, which in the preferred form of the invention are currency or bank notes. 
Devices 36 also include a depository 44 for accepting deposits into a secure location in the 
machine. A receipt printer 46 for providing transaction receipts to customers is also included 
among devices 36. A journal printer 48 is also included among the devices for keeping a 
hard copy record of transaction information. 

Each of the devices is connected to an internal control bus 50 within the banking 
machine 12. The control bus 50 outputs the internal messages to the particular devices. 
Each device has an appropriate hardware interface which enables the particular device to 
operate in response to the messages transmitted to it on control bus 50. Card reader/writer 
38 has a hardware interface schematically shown as 52. Hardware interfaces 54, 56, 58, 60 
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and 62 are respectively operative to connect keyboard 40, sheet dispenser mechanism 42, 
depository mechanism 44, receipt printer mechanism 46 and journal printer mechanism 48 to 
the control bus 50. 

Computer 34 has several software programs that are executable therein. In the 
preferred embodiment of the invention these software programs include a device interfacing 
software portion generally indicated 64. Device interfacing software portion 64 preferably 
includes a software device interface 66 that communicates electronic messages with the 
control bus 50. The device interface software portion 64 also preferably includes a device 
manager 68. The device manager is preferably operative to manage the various devices 36 
and to control their various states so as to be assured that they properly operate in sequence. 
The device manager is also preferably operable to create device objects in the software so as 
to enable operation of the devices by the object oriented program 70. Device interfacing 
software portion 64 also includes the object oriented program portion 70, which in the 
preferred embodiment is an application written in the JAVA language. Program 70 works in 
conjunction with the device manager to receive object oriented JAVA messages which cause 
the devices to operate, and to transmit device operation messages indicative of a manner in 
which devices are operating and/or are receiving input data. 

The device interfacing software portion 64 in the preferred embodiment operates on 
computer 34 and communicates through a physical TCP/IP connection 72 with the intranet 
16. The physical connection may be analog dial-up, serial port, ISDN connection or other 
suitable connection. In the configuration of the system as shown, device interfacing software 
portion 64 communicates at the IP address of computer 34 and at an IP port or socket 
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indicated 74 that is different from the other software applications. In other embodiments of 
the invention, device interfacing software portion 64 may operate in a different computer 
than the other software applications of the invention. 

It should further be understood that although in the preferred embodiment of the 
invention the device interfacing portion 64 is software, in other embodiments of the invention 
all or portions of the instruction steps executed by software portion 64 may be resident in 
firmware or in other program media in connection with one or more computers, which are 
operative to communicate with devices 36. 

Other software also operates in computer 34. This software includes HTML 
document handling software which includes a browser, schematically indicated 76. In the 
preferred embodiment of the invention the HTML document handling software includes a 
browser provided by Netscape®. However in other embodiments other HTML document 
handling and communicating software and browser software, such as Hot JAVA® by Sun 
Microsystems, may be used. Browser 76 communicates in computer 34 at an IP port 
indicated by 78. 

Browser 76 is in operative connection with JAVA environment software 80 which 
enables computer 34 to run JAVA language programs. JAVA language programs have the 
advantage that they operate the same on a variety of hardware platforms without 
modification. This "write once\run anywhere" capability makes the JAVA environment well- 
suited for the preferred embodiment of the invention. However other embodiments may use 
different types of software programs. 
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The JAVA environment software 80 enables computer 34 to execute instructions in 
JAVA script, schematically indicated 82. The instructions that are executed by the computer 
in JAVA script are preferably embedded JAVA script commands that are included in the 
HTML documents which are received through the browser 76. The browser 76 in 
connection with the JAVA environment software 80 which executes instructions in the 
embedded JAVA script 82, serve as an HTML document handling software portion for 
transmitting and receiving HTML documents and TCP/IP messages through the IP port 
indicated by 78. 

Computer 34 also has executable software therein having a device application portion 
84. The device application portion 84 contains executable instructions related to operation of 
the devices 36. In the preferred embodiment of the invention, the device applications portion 
consists of a plurality of JAVA applets. The applets are also preferably operable to control 
and keep track of the status of the devices with which they are associated. Certain applets 
are also preferably operable to configure the browser to communicate messages. Certain 
applets manage security and authenticate entities that use the ATM. 

In the preferred form of the invention, JAVA applets are associated with enabling the 
card reader mechanism, notifying the browser when a user's card data has been entered, 
operating the receipt printer mechanism, operating the journal printer mechanism, enabling 
the customer keyboard and receiving data input through the keyboard, operating the sheet 
dispenser mechanism, verifying digital signatures, handling encryption of messages, 
controlling the mix of bills dispensed from multiple sheet dispenser mechanisms, calculating 
foreign exchange, and ending a transaction and instructing the browser to return to 
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communication with the home server. Of course, in other embodiments, other applets may 
be used to carry out various desired functions or to control devices in the machine. The 
device application portion 84 communicates in the computer 34 at an EP port indicated by 86. 

In the preferred embodiment of the invention, the device application portion 84 of the 
software does not communicate its messages directly to the device interfacing software 
portion 64. As later explained, this provides heightened security. However it should be 
understood that embodiments of the invention may provide for the device application portion 
84 to directly communicate device operation messages to the device program 70. This may 
be done either internally using TCP/IP, by delivery of messages in a conventional manner 
through a queue established in the operating system of the computer that is associated with 
the software that interfaces with the devices, or by direct call to this software. 

From the foregoing discussion it will also be appreciated that certain applets in the 
device application portion 84 may correspond to devices which are not present in all 
automated teller machines. For example an automated teller machine that operates only as a 
cash dispenser does not include a depository mechanism like depository 44. To 
accommodate the situation where a user requests a transaction that is not physically possible 
with the ATM 12, the device interfacing software portion 64 may be programmed to provide 
an appropriate response message to indicate that the function is not available. 

Alternatively, the device interfacing software portion may include a function which 
checks for the presence or absence of each type of physical device within the ATM. 
Information indicative of the devices present in the ATM may be included as part of the 
messages generated by the ATM. For example, information indicative of the devices which 
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are operative in the ATM may be included as part of the URL addresses to which messages 
are directed by the ATM. In this way, the URL in the server to which the ATM connects 
may be configured for providing only HTML documents which correspond to the types of 
transactions that the ATM is capable of performing. 
5 Figure 3 shows the ATM 12 in communication through the intranet 16 with the home 

bank computer system 14. Computer system 14 includes a proxy server 88. System 14 
further includes a home HTTP server 90. Computer system 14 further includes a device 
server 92. The proxy server, home HTTP server and device server may be included in a 
single computer as shown, or in other embodiments may be separate computers. 

10 The home HTTP server 90 is preferably in electronic communication with a back 

office computer system, schematically indicated 94. Back office computer system 94 is 
operative to keep track of debiting or crediting customers' accounts when they conduct 
transactions at the automated banking machines. In addition back office 94 is also preferably 
operative to track transactions for purposes of accomplishing settlements with other 

15 institutions who are participants in the system and whose customers conduct transactions at 
the ATMs 12. 

As later explained, proxy server 88 is also operative to communicate through the wide 
area network 18 with foreign servers such as foreign server 96. Foreign server 96 is an 
example of a server operated by an institution other than the institution which operates 
20 computer system 14. It should be understood that while foreign server 96 is indicated as 
operated by a "foreign" institution, this is not necessarily indicative that the institution is 
located in another country from the institution that operates computer system 14. However, 
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it is possible that foreign server 96 could be located in such a foreign country, including a 
country in which the language spoken is different from that generally used in the country 
where ATM 12 is located. 

The conduct of transactions using the ATM 12 is now explained with reference to 
Figures 3-24. It should be understood that the following described transaction flows are 
merely examples of the operation of the apparatus and system, and the apparatus and system 
may be configured and operated in numerous ways to carry out transactions. 

At the start of an exemplary transaction, as schematically represented in Figure 3, the 
browser 76 communicates through the intranet 16 with the proxy server 88. The 
communication is established preferably in a manner so that HTML documents intended to 
attract customers to the ATM 12 are displayed on the touch screen 30. This is referred to as 
the "attract mode. " These HTML documents which produce the screens on the touch screen 
30 originate from home HTTP server 90 which is operative to deliver the HTML documents 
to the proxy server. The home HTTP server sends the messages addressed to the IP port 
associated with browser 76, so as to cause their display at the proper ATM machine. It 
should be understood that while in this example, home server 90 is described as 
communicating with the ATMs through the proxy server 88, the server 90 may in other 
systems encompassed by the invention communicate directly with the ATMs. 

A fundamental advantage of the system is that home HTTP server 90 may deliver 
documents selectively to the ATMs 12 connected to the intranet 16. These documents may 
include messages tailored to the particular location in which an ATM 12 is located. 
Examples of particularly tailored screens may include bilingual messages in certain 
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neighborhoods or information concerning currency exchange at various ports of entry. The 
JAVA applets and JAVA script are loaded from a central location providing selective 
software distribution in the ATMs which may also be used to tailor the ATM to its 
environment. 

The touch screen 30 in this exemplary transaction displays a screen which includes an 
icon which indicates in one or more languages that to commence a transaction a user should 
touch the screen. If a user touches the screen in the area of the icon an input signal is 
generated. The input signal is transmitted through the browser 76 to the home address of the 
home HTTP server 90 to which the ATM 12 is currently in communication. The message 
generated back to the home HTTP server is represented by the arrows directed from the 
browser 76 to the intranet 16, from the intranet 16 to the proxy server 88, and from the 
proxy server to the HTTP server 90 in Figure 3. 

In response to the home HTTP server 90 receiving the message indicating that a 
customer has touched the icon on the screen, the home server is operative to send a message 
through the proxy server 88 (or in other embodiments directly) to the browser 76. This 
message preferably is an HTML document which produces a screen instructing the customer 
to insert their card into the card reader mechanism 38. The HTML document flow which is 
represented graphically in Figure 4, preferably also includes embedded JAVA script 
instructions which operate in the JAVA environment to communicate a message to the JAVA 
applet responsible for enabling the card reader in the device application portion 84. 

As shown in Figure 5, in response to the embedded JAVA script activating the JAVA 
applet associated with the enable card reader function, the JAVA applet in the device 
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application portion 84 communicates with the device server 92. The device server 92 
includes a device server program 98 which in the preferred embodiment is a JAVA program 
that enables communication with the JAVA applets and the device server application 100. 
The device server 92 further preferably includes a monitor software application 102 which is 
operative to monitor device operation instructions. The monitor software minimizes the risk 
of fraud or abuse in a manner later explained. 

Returning to the sample transaction, in response to receiving the enable card reader 
message from the device application portion 84, the device server 92 is operative to generate 
a message through the intranet 16 to the device interfacing software portion 64 of the ATM 
12. This message is directed to the EP port indicated 74 which is where the device 
interfacing software portion 64 communicates. In response to receiving this message, the 
software portion 64 is operative to send a message on the control bus 50 which enables card 
reader mechanism 34. 

Continuing with the transaction as shown in Figure 6, the input of the card by the 
customer to the card reader 34 is operative to cause the card data to be read and the device 
interfacing program portion 64 to send a message to the device server 92 indicating the card 
data has been read. This message is transmitted by the device server through the intranet 16 
to the device application portion 84. The device application portion then sends a message to 
the device server requesting the card data. The device server 92 transmits a message 
requesting the card data from the device interfacing software portion 64 which responds by 
sending the card data through the intranet to the device server. The device server, if there is 
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no basis for stopping the transaction, transmits the card data back through the intranet 16 to 
the device application portion 84. 

In the preferred embodiment of the invention, the card input by a user or customer 
includes indicia which corresponds to an address associated with the user in the network. In 
the preferred embodiment the indicia corresponds to a uniform resource locator ("URL") 
address which provides information on the computer where the user information resides, as 
well as a directory or subdirectory which includes the user information and the name of the 
. resource that includes the user information. The URL address may be encoded on a 
customer's card. The address may be encoded on track 3 of a magnetic stripe, in other 
locations within the magnetic stripe data or through encoding other readable indicia on the 
card. Alternatively, if the customer's card is a "smart" card which includes semiconductor 
storage thereon, the URL address associated with the customer may be included as part of 
the stored data on the integrated circuit chip on the customer's card. Alternatively, a URL 
could be derived from other data on the card by accessing a data base in which address data 
is correlated with other data read from the card. 

Returning to the exemplary transaction, the delivery of the card data from a 
successfully read card is delivered responsive to the programming of the device application 
portion 84 to a JAVA applet associated with notifying that the card data has been entered. In 
response, the JAVA applet operates to generate JAVA script which configures the browser 
with the URL address from the card. The JAVA applet is also preferably operative to open 
a record schematically indicated 104 concerning the transaction, which includes the user's 
URL address, the time and other card data. 
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As schematically shown in Figure 7, in response to the browser 76 receiving the URL 
address data, the browser is operative to transmit a message through the intranet 16 to the 
proxy server 88. For purposes of this example, the URL address associated with the card 
data is that of a customer associated with the home bank which operates system 14. As a 
5 result, the customer's URL address will cause the message to be directed from the proxy 

server 88 to the home HTTP server 90. Alternatively, in other systems the connection may 
be made directly with server 90 without the intervening proxy server 88. As previously 
discussed, the URL address may also include data representative of the devices which are 
operative in the ATM. 

10 In response to receiving the message, home HTTP server 90 finds the data 

corresponding to the customer's URL address data in memory and responds back to the web 
browser at its IP port with an HTML document. This HTML document may include a 
screen acknowledging the particular customer by name as well as with the name of the 
banking institution or other entity which operates the home bank computer system 14. 

15 In addition, the HTML document preferably includes embedded JAVA script which 

has a digital signature or a means to obtain a digital signature associated with the home 
HTTP server 90. This digital signature is received from the JAVA script 82 and processed 
in a JAVA applet in the device application portion 84. The JAVA applet for processing the 
digital signature authenticates it and authorizes operation of the banking machine. 

20 Alternatively or in addition the applet may check the signature against a listing of digital 

signatures for servers which are authorized to operate the banking machine. After the applet 
verifies that server 90 has sent a proper digital signature, the transaction will be allowed to 
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continue. If for some reason a proper digital signature has not been sent, the JAVA applet 
will stop the transaction and return banking machine 12 back to the condition prior to the 
start of the transaction by connecting the ATM to the address associated with the attract 
mode in home server 90. 

In the example it will be assumed that the digital signature sent by home server 90 is 
a proper signature, in which case a message is returned from the browser 76 to home server 
90 indicating that the transaction may proceed. As shown in Figure 8, in this exemplary 
transaction the HTTP home server 90 then operates to send an HTML document to the 
browser 76 which includes a page or screen which instructs the customer to enter their 
personal identification number or PIN. This HTML document preferably includes embedded 
JAVA instructions to have the device application portion 84 enable the keyboard 40 of the 
ATM so the machine may receive the PIN number. Such a message is schematically shown 
in Figure 8 with the JAVA script 82 signalling the JAVA applet responsible for the keyboard 
that it has been requested to enable the keyboard. In response the JAVA applet in the device 
application portion 84 sends a message through the intranet 16 to the device server 92. The 
device server 92 sends a message back through the intranet to the device interfacing software 
portion 64 in the ATM. This message causes the device software to enable keyboard 40. 
The JAVA applet responsible for enabling the keyboard is also preferably operative to update 
the transaction record 104 to indicate that the PIN was requested. 

As shown in Figure 9, the PIN entered through the keyboard 40 is transmitted from 
the device interfacing software portion 64 to the device server 92. The device server 92 
returns a message to the responsible JAVA applet in the device application portion. The 
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JAVA applet then operates to cause the JAVA script to send a message back through the 
HTML document handling portion and the browser 76 to the HTTP home server 90. This 
message includes data representative of the PIN input by the customer. 

The HTTP server 90 is then operative to either verify the PIN itself or to verify the 
customer's PIN number and account number by sending it to the back office 94 and waiting 
for a response. Alternatively, customer PIN verification may be carried out in the ATM 
through an appropriate applet. This can be done in situations where data on a customer's 
card, such as an account number, can be correlated to the customer's PIN number through an 
algorithm. The embedded JAVA script in the HTML messages may include the data which 
the applet uses to perform this verification function, including certain encryption key data. 
As shown schematically in Figure 9, the transaction record 104 is also appropriately updated 
by the applet to indicate the entry of the customer's PIN. 

It should be noted that the page or screen which requests the customer to enter their 
PIN is generated from the home HTTP server 90. This is preferably a screen that is 
associated with the particular customer's URL address. This will be the interface of the 
customer's home bank and will be familiar to the customer. Alternatively, the customer 
address may access what may be essentially the customer's personal "home page" with the 
institution that operates computer system 14. As such, it is not only something the user is 
familiar with, but is ideally tailored to the user's particular transaction needs. 

The continuation transaction flow for this exemplary transaction by a customer of the 
institution that operates computer network 14, is schematically shown in Figure 10. The 
home HTTP server 90 is operative in response to the customer inputting the correct PIN to 
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send HTML documents to the HTML document handling portion of the software in the 
computer which operates the ATM. These messages may include screens which prompt the 
customer to select a transaction. For purposes of this example, it will be assumed that the 
customer inputs at the touch screen 30 a selection which corresponds to the dispense of cash, 
which is a common transaction at an automated banking machine. 

The selection of the customer through the input device of the touch screen is 
communicated back through the HTML document handling portion which communicates a 
message to the home HTTP server 90. Server 90 then responds by sending another HTML 
document to the banking machine which prompts the customer to select an amount. Again 
the customer may input a selection on the touch screen which indicates the amount of cash 
requested by the customer. This input message again passes through the HTML document 
handling portion and the browser 76 back to the home server 90. 

In response to the receipt of amount data from the customer, the home server 90 is 
preferably operative to communicate electronically with the back office 94 to verify that the 
customer has the amount requested in their account. This is preferably accomplished through 
a Common Gateway Interface (CGI) 106 which is in operative connection with the home- 
server 90. For purposes of this transaction it will be assumed that the back office 94 
indicates that the money is available in the customer's account and sends a message through 
the CGI 106 to the home server 90 indicating that it may proceed. 

As schematically represented in Figure 11, the home server 90 then operates to send a 
document back to the HTML document handling portion in the ATM software. This 
message preferably will cause information to be displayed on the screen which advises the 
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customer that the transaction is being processed. In addition the HTML document preferably 
includes JAVA script with embedded instructions which are executed and communicated to a 
JAVA applet associated with the operation of the sheet dispensing mechanism 42. 

The message to the JAVA applet in the device application portion 84 of the software 
results in generation of a TCP/IP message to the device server 92. The message to the 
device server 92 to dispense cash is preferably analyzed by the monitor software 102 to 
check to see if the message is appropriate. Specifically the monitor software 102 is 
preferably operative to assure that the amount of cash being requested does not exceed a 
preset amount. It can also optionally check to verify that the amount provided to this 
customer within a prior period has not exceeded an amount. This may be done by the device 
server sending a message to the back office which includes the card data it has previously 
received from this customer. This message may pass through server 90 and its associated 
CGI, or other connection. Assuming that the dispense instruction is not prevented by a 
message from the back office or the monitor software, the device server 92 is operative to 
send a dispense message to the device interfacing software portion 64 in the ATM. The 
software portion 64 is thereafter operative to operate the sheet dispensing mechanism 42 to 
dispense the amount of cash requested by the customer. 

The monitor software 102 preferably performs additional functions in the device 
server. For example, government regulations or good business practice may require limiting 
the size and amounts of deposits which may be made into an ATM. This may be advisable 
to prevent "money laundering" or other suspicious activities. The monitor software 
preferably operates to limit the amount of any single deposit to below a set limit. It further 
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operates by communicating with the home bank back office system 94 to prevent a series of 
deposits within a preset time from exceeding a certain limit. The monitor software may also 
work in connection with the proxy server to limit certain transactions that may be carried on 
at the banking machine responsive to instructions from foreign servers as later discussed. 

It should be noted that in a preferred embodiment of the invention the JAVA applet 
which is operative to send the message which causes cash to be dispensed, works in 
connection with another applet which controls the mix of bills dispensed to a customer. 
Many automated teller machines have the ability to dispense two or more denominations of 
currency bills. It is desirable to control the mix of bills dispensed to a customer to suit that 
which is available in the machine and to avoid running out of one denomination of bills 
before the other. The bill mix applet is preferably operable to control the bill mix in 
accordance with the desires of the institution operating the ATM machine as well as is in 
accordance with the ATM machine's capabilities. Alternatively, a JAVA applet for 
controlling bill mix may reside in device program 70 in device interfacing software portion 
64. 

As will be appreciated by those skilled in the art, the particular JAVA applets in the 
machine may be selectively loaded from the home server 90 at machine start up. Because 
the applets may be selectively delivered to particular machines, they may be tailored 
specifically to the particular ATMs currency dispensing capabilities. 

In response to the cash dispenser 42 dispensing the requested amount of cash, device 
interfacing software program 64 preferably operates to send a dispense operation message 
confirming the dispense back to the JAVA applet responsible for the dispense in the device 
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application program 84. As represented in Figure 12, the particular applet is operative to 
update the transaction record 104 to indicate the dispense of currency to the customer in the 
particular amount. The embedded JAVA script instructions which were operative to cause 
the dispense of currency to the customer, also preferably include instructions to send a 
confirming message back to the home server 90 that the dispense is complete. The receipt of 
the dispense operation message indicating the cash was dispensed causes the JAVA applet to 
configure the HTML document handling portion to send a device response message back to 
the home server. The home server then is preferably operated in accordance with its 
programming to indicate to the back office 94 that the customer received the amount of funds 
dispensed. This amount is deducted from the customer's account in the records maintained 
by the back office system. 

Generally during a transaction it is common to ask the customer if they wish to have 
a receipt for the transaction. This may be done at various times during the transaction flow. 
In the present example, after the cash has been dispensed the customer operating the machine 
is sent such a message as reflected in Figure 13. The home server 90 is operative to send an 
HTML document which includes a screen asking the customer if they would like a receipt. 
This message is displayed as part of a page on the touch screen 30 responsive to receipt of 
the message through the browser 76. In response to the customer indicating that they do or 
do not want a receipt, a message is returned to the home server. Again it should be 
understood that the screens displayed to the customer are those that the customer is 
accustomed to from his or her home institution, and may be a part of his or her unique home 
page. 
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Assuming that the customer wishes to receive a transaction receipt, the home server 
90 operates as shown in Figure 14 to send a document back to the ATM with embedded 
JAVA script indicating that a transaction receipt is to be printed. These instructions in 
JAVA script are communicated to the device application portion 84 which sends a TCP/IP 
message through the intranet to the device server 92. The device server 92 in turn 
communicates with the device interfacing software portion 64 in the ATM. In response to 
receiving the message, software portion 64 is operative to cause the printer 46 to print the 
customer's transaction receipt. The JAVA applet responsible for enabling the printer is also 
preferably operative to update the transaction record 104. 

It should be understood that even if the customer does not wish to have a receipt it is 
desirable to print a record of the transaction in hard copy through the journal printer 48. 
This may be accomplished in response to imbedded instructions which are part of the same 
document from the home server 90 which causes the transaction receipt for the customer to 
be printed, or may be part of a separate document which indicates that the customer has 
declined the option to receive a transaction receipt. Alternatively, the journal printer may be 
actuated responsive to other applets such as the applet which causes the dispense of cash, or 
in another manner chosen by the operator of the ATM. As will be appreciated from the 
foregoing description the operation of the preferred embodiment of the ATM is inherently 
flexible and programmable to meet the needs of the system operator. 

As shown in Figure 15 upon completion of the printing of the transaction receipt, the 
software portion 64 is preferably operative to send a device operation message to the device 
server 92 which is indicative that the requested device function was carried out successfully. 
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The device server 92 is operative to send a corresponding device operation message to the 
device application portion 84, and in the preferred embodiment to the particular JAVA applet 
responsible for the printing of the receipt. The JAVA applet in turn configures the HTML 
document handling portion to generate a message back to the home server in the form of a 
device response message to indicate that the receipt was printed for the customer. 

Having received cash and a receipt, the customer is then prompted by an HTML 
document from the home server 90 to indicate whether they wish to conduct another 
transaction. A page or screen prompting the customer in this regard is displayed at the touch 
screen 30. For purposes of this example it will be assumed that the customer does not want 
another transaction and a message to that effect is returned through the HTML document 
handling portion back to the home server 90. 

As shown schematically in Figure 17 in response to receiving a message that the 
customer is done, the home server 90 is operative to send a "go home" message to the ATM. 
This message preferably includes an HTML document thanking the customer, as well as 
embedded JAVA script which calls the JAVA applet which eventually returns the HTML 
document handling portion of the ATM back into connection with the URL address on the 
home server 90 which carries on the messages for the so called "attract mode". 

As schematically indicated in Figure 18, the "go home" command applet is operative 
to configure the browser 76. After the HTML document handling portion is configured by 
the JAVA applet to return home, the JAVA applet may be configured to deliver to home 
server 90 information from the transaction record 104 concerning the transaction that was 
just completed. Because the exemplary transaction was with a customer of the institution that 
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operates the computer system 14, all the data concerning that transaction should already be 
recorded in the back office 94. However it will be appreciated that this will not be the case 
if the transaction was conducted in response to messages from a server operated by a 
different institution. Thus, the information from the transaction record 104 may be delivered 
in response to a "go home" command to the home server 90 and through the CGI to the back 
office system 94 where it can be identified as duplicate information and discarded. 

Of course in other embodiments transaction information may be stored in a database 
for extended periods rather than being returned after each transaction. Alternatively the 
ATM 12 of the present invention may include applets which are operable to deliver 
transaction record information to addresses other than that of the home server, if that is 
desired by the operator of system 14. 

The operation of the computer system when a "foreign" user uses the ATM 12 is 
graphically represented with regard to Figures 19 through 24. A transaction with a foreign 
user who is not a customer of the institution that operates ATM 12 and computer system 14, 
will be operated under the control of the home server 90 and will proceed in the manner of 
the prior example through the point where the customer inputs their card. The customer 
inputs a card having indicia corresponding to a URL address that does not correspond to the 
home server 90. The HTML document handling portion is operative to configure a message 
addressed to a URL address that corresponds to the indicia on the customer's card. This 
message is delivered to the proxy server 88 which in turn passes the message to the wide 
area network 18. From the wide area network the message proceeds to the foreign server 
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corresponding to the customer's URL address. For purposes of this example the foreign 
server corresponds to server 96 which is connected to the Internet. 

In the preferred embodiment of the invention proxy server 88 includes screening 
software graphically indicated 107. Screening software is preferably operable to check 
addresses to which messages are being directed by the ATM and to selectively prevent the 
sending of messages to particular addresses. This serves as a "fire wall" and is desirable for 
purposes of preventing fraud in the system. 

As shown in Figure 20, the foreign server 96 is preferably operable to communicate 
documents to the ATM 12 back through the wide area network 18. This is preferably done 
using a secure socket connection ("SSC") so as to minimize the risk of interception of the 
messages. Of course other techniques, including encryption message techniques may be used 
to minimiz e the risk of interception of the messages. 

As schematically represented in Figure 20 the response document from foreign server 
96 preferably includes embedded JAVA script representative of a digital signature which 
corresponds to and identifies the foreign server 96. An applet device in application portion 
84 in the ATM preferably operates to authorize the digital signature in the manner described 
in the prior example, and sends a message indicating that the transaction has been authorized. 
The digital identity of the foreign institution will be stored in the ATM and eventually 
recorded in the back office 94. 

It should be noted that the HTML documents from the foreign server 96 produce the 
pages or screens of the foreign institution which the foreign customer is accustomed to 
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seeing. Preferably these pages correspond to the foreign user's "home page" which are 
tailored specifically to the needs of the particular user. 

Figure 21 shows an example of a document coming from the foreign server 96 to the 
ATM 12. The document from the foreign server may include embedded JAVA script which 
enables operation of the JAVA applets in the manner previously discussed to operate the 
devices 36 in the ATM. As shown in Figure 21 the TCP/IP messages to the devices from 
the JAVA applets pass from the device application portion 84 to the device server 92, and to 
the device interfacing software portion 64 in the ATM. Device operation messages take a 
reverse path. As these messages pass through the device server 92, monitor software 102 
monitors them to minimize the risk of fraud or abuse. 

As indicated in Figure 21, the documents from the foreign server 96 may be operative 
to display at the touch screen 30 a request for the customer to input their PIN. The 
embedded JAVA script instructions would, as in the sample transaction previously discussed, 
include instructions that enable the keyboard 40 to accept the customer's PIN. As in the 
prior example, a transaction record 104 concerning this transaction would be opened by the 
device application software portion. 

Figure 22 indicates the return of the device operation message and PIN data to the 
JAVA applet which in turn transmits the data back to the foreign server 96 through the wide 
area network 18 using the secure socket connection. From this point the transaction proceeds 
generally as previously described, except that the foreign server 96 sends the HTML 
documents and receives the TCP/IP messages from the HTML document handling portion of 
the ATM. The foreign server 96 includes the JAVA application software necessary to 
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include the embedded JAVA script in the documents that are sent to the ATM to operate the 
devices 36 in the machine. As the foreign server 96 operates the machine however, the 
monitor software 102 in the device server 92 is operative to monitor the messages in the 
manner previously discussed. Such monitoring would for example, operate to prevent the 
dispense of unduly large amounts of currency out of the machine. 

As can also be appreciated from the foregoing disclosure, the foreign server 96 may 
communicate to the user through the touch screen in a language that is different from that 
normally used by the customers of the institution that operates the computer system 14. As a 
result the HTML documents may display requests to dispense currency of a type or in an 
amount which is not included in the ATM. To accommodate this situation an applet is 
included in the device application portion 84 to deal with requests for foreign currency. The 
foreign currency applet causes the ATM to send a message back to its home server for 
purposes of calculating a closest amount which may be provided to the customer in the 
available currency in the ATM which corresponds to what the customer requested. As will 
be appreciated, this applet will be operative to call the particular function address within the 
home server 90 that is capable of providing this function. When the dispense is made the 
applet is also operative to indicate to server 96 that the amount dispensed differs somewhat 
from the amount the customer requested. Of course in other embodiments, other approaches 
may be used. 

As represented in Figure 23, when the foreign customer has completed their 
transactions as indicated through the touch screen 30, the foreign server 96 is operative to 
send the "go home" message back to the ATM. The receipt of this message is operative in 
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the manner previously described to cause the device application portion 84 to operate 
responsive to the embedded JAVA script instructions to configure the HTML document 
handling portion to cause the browser 76 to reestablish communication with the home server 
90. 

As indicated in Figure 24 the applet in the device application portion 84 which 
processes the "go home" message is preferably operative to reconnect to the home server 90 
as well as to send the transaction record information in record 104. This transaction record 
information which includes the customer name, the foreign institution name, digital 
identifier, amount information and all other pertinent transaction data is communicated to 
server 90 through the CGI 106 to the home bank's back office 94. This information is 
stored in the back office for later use for purposes of settlement with the foreign bank 
operating the foreign server 96. 

It will be appreciated that the preferred embodiment of the automated banking 
machine and system of the present invention provides the advantage that when the machine is 
connected to a wide area network such as the Internet, customers are able to carry out their 
banking transactions virtually anywhere in the world. Further, despite the broad capabilities 
of the system, because the machine is monitored locally, both in terms of connection and 
activity, the risk of fraud is minimized. 

While the preferred embodiment of the automated banking machine and system of the 
present invention is shown with regard to a particular type of machine that is made 
specifically for collectibility to wide area networks, conventional automated banking 
machines may also be adapted to include such capability. Specifically the HTML document 
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handling portion and device application portions may be included with other conventional 
software which operates within an automated banking machine. This enables such ATMs to 
operate either in the conventional proprietary network or as part of a wide area network. In 
addition, automated banking machines may be configured to operate their devices through the 
5 device interfacing software portion of the invention or through a different software interface 
when operating in a conventional network. Such machines may switch to requiring device 
messages to be passed through a device server when operating under the control of a server 
within the wide area network to maintain security within the system. In this way a single 
ATM could operate in proprietary networks in the manner of current ATMs as well as in the 

10 network configuration of the system of the invention. 

Alternative embodiments of the invention operate to communicate transaction 
messages used in a proprietary ATM network. This may be accomplished by using a CGI in 
connection with either the HTML document handling portion of the ATM or the HTTP home 
server. The CGI operates in connection with a message conversion program to cull the 

15 necessary data from the HTML documents and TCP/IP messages and generates the 

transaction request messages appropriate for the proprietary transaction network. Likewise, 
the message conversion program and CGI operate to receive function command messages 

from the proprietary network and convert them to appropriate HTML documents and/or 

> 

TCP/IP messages for use by the ATM. Because these proprietary network formats are 
20 defined and the data necessary to produce and interpret the messages are known, the use of 
the ATM 12 directly in a conventional proprietary ATM network is achieved. 
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The ability of ATM 12 to communicate in a proprietary network also enables 
operation of the ATM in a manner in which the interface is generated by a user's home 
institution in the manner previously described, but in which transactions are authorized 
through messages directed through a proprietary ATM network. This achieves the security 
of using the proprietary network while providing the customer with the advantages of the 
familiar home bank interface and/or "personal home page" interface. 

A further advantage of the system configuration of the preferred embodiment is that it 
has enhanced flexibility for communicating messages associated with the ATM. The device- 
manager 68 preferably generates status messages associated with the status of devices 36. 
These status messages may commonly represent information about conditions which exist at 
the devices. Such messages may indicate that supplies of paper for printers or currency, are 
low or are depleted. Other messages may indicate that devices are not functioning properly. 
Often such messages indicate that the ATM requires servicing. 

The device interfacing software portion 64 communicates through the intranet 16 
using TCP/IP messages. While the messages associated with transactions previously 
described are directed to the device server 92, the software portion 64 may be configured to 
address fault messages to other addresses in the intranet. For example, such fault messages 
may be directed to a software application which delivers messages to a service provider. 
Further, fault messages may be selectively directed based on the nature of the fault indicated. 
For example, fault messages indicative of a need to replenish currency or supplies may be 
directed to an address in the intranet associated with an entity who has responsibility for 
replenishing supplies. Alternatively, fault messages which indicate a need for other types of 
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servicing may be directed to an address associated with an entity who can provide the type of 
servicing required. 

Alternatively, the selective dispatching of fault messages to addresses in the intranet 
16 may be accomplished by appropriately configuring device server 92. In addition, either 
5 software portion 64 or device server 92 may direct fault messages from the ATMs to a fault 
handling system such as to a computer operating Event Management System™ software 
available from Diebold, Incorporated. Such software is operative to resolve the nature of the 
fault condition and to notify appropriate personnel of the corrective action to be taken. 
Thus the new automated banking machine and system of the present invention 
10 achieves the above stated objectives, eliminates difficulties encountered in the use of prior 
devices and systems, solves problems and attains the desirable results described herein. 

In the foregoing description certain terms have been used for brevity, clarity and 
understanding. However no unnecessary limitations are to be implied therefrom because 
such terms are for descriptive purposes and are intended to be broadly construed. Moreover 
15 the descriptions and illustrations herein are by way of examples and the invention is not 
limited to the details shown and described. 

In the following claims any feature described as a means for performing a function 
shall be construed as encompassing any means capable of performing the recited function and 
shall not be deemed limited to the particular means shown in the foregoing description or 
20 mere equivalents thereof. 

Having described the features, discoveries and principles of the invention, the manner 
in which it is constructed and operated and the advantages and useful results attained; the 
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new and useful structures, devices, elements, arrangements, parts, combinations, systems, 
equipment, operations, methods, processes and relationships are set forth in the appended 
claims. 
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CLAIMS 



Apparatus comprising: 

a banking machine, including: 

an output device, wherein such output device outputs information to a 
user; 

an input device, wherein a user is enabled to input messages to said 
machine; 

a sheet dispenser mechanism; 

a computer, wherein said computer is in operative connection with the 
output device, the input device and the sheet dispenser mechanism; 

software executable in said computer, said software including: 

an HTML document handling portion in operative 
connection with the input device and the output device, 
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wherein said HTML document handling portion is 
operative to receive HTML format documents; 



a device application portion in operative interfacing 
relation with the HTML document handling portion, 
wherein said device application portion is in operative 
connection with the sheet dispenser, and wherein said 
device application portion is operative responsive to the 
HTML document handling portion receiving an HTML 
format document including a dispense instruction to 
cause the sheet dispenser mechanism to dispense at least 
one sheet. 

2. The apparatus according to claim 1 and further comprising a card reader mechanism 
in operative connection with the HTML document handling portion of the software, and 
wherein the card reader is operative to accept a card, wherein said card includes indicia 
thereon, and wherein said indicia corresponds with a system address associated with the user, 
and wherein said HTML document handling portion is operative to cause a message to be 
generated to the system address responsive to said card indicia. 

3. The apparatus according to claim 2 wherein the system address for the user includes a 
URL address. 



39 



4. The apparatus according to claim 1 wherein in said banking machine said HTML 
document handling portion and said device application portion both communicate messages 
through TCP/IP, and wherein said HTML document handling portion communicates at a first 
IP port and said device application portion communicates at a second IP port. 

5 5. The apparatus according to claim 4 wherein the software in the banking machine 

further comprises a device interfacing software portion, and wherein said device interfacing 
software portion is operative to interface with said sheet dispenser mechanism, wherein said 
application portion interfaces with said sheet dispenser mechanism through said device 
interfacing software portion, and wherein said device interfacing software portion 

10 communicates at a third IP port. 

6. The apparatus according to claim 1 wherein said HTML document handling portion 
includes a browser. 

7. The apparatus according to claim 1 wherein said dispense instruction is an embedded 
instruction. 

15 8. The apparatus according to claim 1 wherein said dispense instruction is in JAVA 
script. 
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9. The apparatus according to claim 1 wherein said device application portion includes a 
first applet, wherein said first applet is operative to cause operation of said sheet dispenser 
mechanism. 

10. The apparatus according to claim 1 wherein said banking machine further comprises a 
printer mechanism, wherein said printer mechanism is in operative connection with said 
computer, and wherein said printer mechanism is operative responsive to the device 

. application portion of the software, and wherein said printer mechanism is operative to print 
responsive to receipt of a print instruction by said HTML document handling portion. 

11. The apparatus according to claim 1 wherein said banking machine further comprises 
at least one device, said device being one of a printer mechanism, a card reader mechanism 
or a depository mechanism, and wherein said device is operative responsive to the device 
application portion of the software, and wherein the device is operative responsive to receipt 
of a device instruction by the HTML document handling portion. 

12. The apparatus according to claim 1 wherein said dispenser mechanism is operative 
responsive to dispensing said sheets to cause a dispenser operation message to be delivered to 
the device application portion of the software, and wherein said HTML document handling 
portion is operative responsive to delivery of the dispenser operation message to output a 
dispense response message from said HTML document handling portion. 
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13. The apparatus according to claim 11 wherein the device is operative responsive to its 
operation to cause a device operation message to be delivered to the device application 
portion of the software, and wherein the HTML document handling portion is operative 
responsive to the delivery of the device operation message to output a device response 
message from the HTML document handling portion. 

14. The apparatus according to claim 12 wherein the HTML document including the 
dispense instruction includes a response instruction, wherein said response instruction is 
operative to cause the output of the dispense response message responsive to delivery of the 
dispense operation message to the device application portion of the software. 

15. The apparatus according to claim 1 and wherein said banking machine further 
comprises a plurality of devices, said devices operative responsive to the device application 
portion of the software, and wherein said device application portion includes at least one 
applet operative to control at least one of said plurality of devices. 

16. The apparatus according to claim 15 and wherein said software further comprises a 
device interfacing software portion operative to interface with said devices, and wherein said 
device interfacing software portion includes a device program operative to interface with said 
one applet. 
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17. The apparatus according to claim 16 wherein said applet is operative to communicate 
through a second IP port and the device program is operative to communicate through a third 
IP port. 

18. The apparatus according to claim 1 and further comprising a home HTTP server in 
operative connection with the HTML document handling portion of the banking machine, and 
wherein the home HTTP server is operative to send HTML documents to the HTML 
document handling portion of the software in the banking machine. 

19. The apparatus according to claim 18 wherein the home HTTP server is operative to 
send the dispense instruction to the banking machine. 

20. The apparatus according to claim 18 wherein the home HTTP server includes a home 
address, and wherein the HTML document handling portion of the software is operative to 
send a message to the home address in response to a user input at said input device. 

21. The apparatus according to claim 18 wherein said home HTTP server has a home 
address, arid wherein said banking machine further comprises a card reader mechanism in 
operative connection with said device application portion of the software, whereby said card 
reader mechanism is operative to read card indicia on a card input by a user, and wherein 
said HTML document handling portion is operative to send a message to the home HTTP 
server responsive to the card indicia corresponding to the home address. 
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22. The apparatus according to claim 21 wherein said card indicia further corresponds to 
identifying information associated with a file, wherein said file is associated with the user, 
and wherein said file is stored in operative connection with the home HTTP server. 

23. The apparatus according to claim 22 wherein said card indicia includes a URL 
address associated with the user. 

. 24. The apparatus according to claim 22 wherein the file includes at least one HTML 
document associated with the user. 

25. The apparatus according to claim 18 and further comprising a proxy server in 
operative connection with the home HTTP server, wherein the home HTTP server has a 
home address, and said HTML document handling portion has a machine address, and 
wherein said proxy server is operative to direct messages from said banking machine to the 
home HTTP server responsive to said messages including the home address. 

26. The apparatus according to claim 25 wherein the proxy server is also in operative 
connection with a wide area network, and wherein said wide area network includes a foreign 
server, wherein said foreign server has a foreign address, and wherein said banking machine 
further includes an address input device in operative connection with the HTML document 
handling portion, and wherein the HTML document handling portion is operative responsive 
to input of the foreign address through said address input device to generate a foreign 
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message addressed to the foreign address, and wherein said proxy server is operative 
responsive to receipt of the foreign address to pass the foreign message to said wide area 
network 

27. The apparatus according to claim 26 wherein said proxy server includes screening 
software, wherein said screening software is operative to prevent the sending of the foreign 
message to at least one selected foreign address. 

28. The apparatus according to claim 26 wherein said proxy server is operative responsive 
to receiving a foreign response message from said foreign address directed to said machine 
address to pass the message to said HTML document handling portion of the software in said 
banking machine. 

29. The apparatus according to claim 5 and further comprising a device server, wherein 
said device application portion of said software and said device interfacing software portion 
communicate through said device server. 

30. The apparatus according to claim 29 wherein said device server includes monitor 
software, wherein said monitor software is operative to limit operation of said sheet 
dispensing mechanism. 



45 



ABSTRACT 

An automated banking machine (12) is operative to conduct transactions in response 
to HTML documents and TCP/IP messages exchanged with a local computer system (14) 
through an intranet (16), as well as in response to messages exchanged with foreign servers 
(20, 22, 24, 26, 28, 96) in a wide area network (18). The banking machine includes a 
computer (34) having an HTML document handling portion (76, 80, 82). The HTML 
document handling portion is operative to communicate through a proxy server (88), with a 
home HTTP server (90) in the intranet or the foreign servers in the wide area network. The 
computer further includes a device application portion (84) which interfaces with the HTML 
document handling portion and dispatches messages to operate devices (36) in the automated 
banking machine. The devices include a sheet dispenser mechanism (42) which dispenses 
currency. The device application portion communicates with a device interfacing software 
portion (64) in the banking machine through a device server (92) in the intranet. The device 
server maintains local control over the devices in the banking machine including the sheet 
dispenser. The banking machine operates to read indicia on the user's card corresponding to 
a system address. The computer is operative to connect the banking machine to the home or 
foreign server corresponding to the system address, which connected server operates the 
banking machine until the completion of transactions by the user. 
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BACKGROUND OF THE IN VENTION 



1. FIELD OF THE INVENTION 



5 The present invention relates to the field of electronic billing and paying 

systems. More particularly, the present invention relates to an electronic 
fi statement delivery system. 
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BACKGROUND ART 



p Every month, millions of customers receive bills and other monthly 

g statements from utilities, banks, stores, credit card companies, insurance 

W . companies, and other service providers. Almost all of these bills are sent by 
J* mail. A typical bill includes four primary components: 



1. Summary information. Typically includes an amount due, a due 
date, a customer account number, a biller name and address. The summary 
information is often printed on a detachable remittance. stub that is intended to 
be returned by the customer with a check for payment 

2. A pre-addressed return envelope. 



3. Detailed invoice of charges. Typically includes a detailed listing of 
the charges accrued. For example, if the bill is a telephone company bill, the 
25 detailed invoice will list details of each toll call. The detailed information may 
include legally mandated information, particularly if the biller is a public utility. 
For example, an electric company may be required to list monthly or yearly 



comparisons of a customer's energy use. The content and format of such legally 
mandated information may vary from one legal jurisdiction (town, county, state) 
to another. 



5 4. Marketing materials. Billers typically include information such as 

newsletters announcing new products or services, and often also include third 
party advertising pieces. 

A customer typically pays a bill by writing a check for the amount due, 
10 placing the check and the remittance stub in the return envelope, sealing and 
stamping the envelope, and placing it in the mail. 

For every bill received and paid by a customer, a billing institution (biller) 
has to perform numerous paper handling tasks. First the biller has to generate 

15 the bill and mail it to the customer. The bill generation process involves 

retrieving billing data for a customer, formatting the billing data in the legally 
prescribed manner, printing each customer's bill, placing the bill and other 
included materials in an envelope, and mailing the envelope to the customer. 
The biller also has to process the payment remittance received. Remittance 

20 processing involves opening envelopes, identifying the customer's account, 
extracting the check, and presenting the check for payment. Given the large 
volume of bills sent out and payments received each month, the paper handling 
involved is a large and expensive undertaking. 



25 



Various systems have been proposed to reduce the paper handling 
involved in bill paying and remittance processing. For example, there exist 
electronic bill payment service bureaus that allow customers to electronically 
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pay their bills via a home computer or telephone. Although use of these bureaus 
make bill paying more convenient for customers, they make remittance 
processing more expensive for billers. When using a bill payment service, a 
customer directs the service bureau to make payments to the biller. The 

5 payment origination is usually done electronically. As a result, the remittance is 
not presented to the biller in the usual way, i.e. a check with the biller's 
remittance stub in a single envelope. Instead the biller usually receives a check 
printed by the service bureau drawn on the customer's bank account. Instead of 
being accompanied by a remittance stub, the customer's account number with 

10 the biller is printed on the check. Because this form of remittance is different 
from the usual remittance received by the biller, the biller must process it in a 
special manner, incurring additional expenses. 

U.S. Patent No. 5,465,206, issued November 7, 1995, for "Electronic Bill 
15 Pay System", assigned to the assignee of the present invention and incorporated 
herein by reference, discloses a bill pay system that allows customers to pay bills 
to participating billers through a centralized payment network operating 
according to preset rules. The participating customers receive bills from 
participating billers which indicate an amount owed and a unique biller 
20 identification number, which is assigned by the payment network. The bills 
may be mailed bills, e-mail notices, or implied bills for automatic debts. To 
authorize a remittance, a customer transmits to its bank, which is a participating 
bank, a bill pay Order indicating a payment date, a payment amount, the 
customer's account number with the biller, a source of funds, and the biller's 
25 biller identification number. The customer's bank then submits a payment 
message to a payment network. The payment network forwards the payment 
message to the biller's bank. For settlement, the customer's bank debits the 
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customer's account and is obligated to a net position with the payment network. 
Likewise, the biller's bank receives a net position from the payment network and 
credits the biller's bank account. The customer initiates bill pay orders manually 
via paper correspondence, at an ATM, via PC, or via telephone keypad. 

Prior art systems have primarily addressed the bill payment portion of 
customer bill processing. The bill generation and presentation portion of 
customer bill processing has not yet been satisfactorily addressed. U.S. Patent 
O No. 5,465,206 suggests that bills may be sent electronically by e-mail, but does 
S 10 not elaborate. U.S. Patent No. 5,007,084 for "Payment Authorization and 
Information Device", issued April 9, 1991, describes a home terminal for 
receiving and printing out billing information. The billing data is simple text 
data received by. the customer via an encoded signal broadcast by a centralized 
invoice distribution center during vertical blanking intervals of a television 
g 15 broadcast or via telephone lines and a modem. A special device is used to 
| decode and print out a hard copy of the received text. The same device can be 
m used to pay the bill electronically. 

The electronic bills delivered by these systems consist of simple text 
20 messages. As such, the electronic bills cannot deliver the same variety of 

information and materials as, and are therefore a poor substitute for, traditional 
mailed paper bills. 
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ST IMMARY O P THF. INVENTION 



The present invention consists of an electronic invoice presentation (EIP) 
system that can be used in conjuction with an electronic bill pay system to 
5 provide a comprehensive electronic bill generation, presentation, and payment 
system. Participants include consumers, consumer financial institutions or 
| service providers (CSI/SP), a transport network, biller banks, and billers. 
3 Components of the system include a Universal Biller File (UBF), a set of control 
g and maintenance transactions, and an invoice delivery system. The UBF is a 
| 10 control file containing key information about all billers participating in the EIP 
| service. The UBF is used to identify billers, to communicate biller service 
g options, to perform process edits on data transported between a CSI/SP and a 
S biller, and to support CFI/SP service packaging! The control and maintenance 
U transactions include service requests, biller requests/confirmations, and CFI/SP 
| 15 notification. These transactions ensure that the EIP service performs with 
S certainty and flexibility. The invoice delivery system supports a variety of 

9 invoice types and delivery options, including delivery of summary invoices to a 

consumer by a certified CFI/SP (a certified CFI/SP is a CFI/SP that meets 
certain minimum security requirements), delivery of full detail invoices 
20 supporting biller defined graphics and colors by a certified CFI/SP, and invoice 
notification by an uncertified CFI/SP with delivery of summary or full detail 
invoices by a central secure facility. The present invention provides a secure 
electronic invoice presentation system that is flexible enough to accomodate 
almost any biller and any bill or invoice format, and allows convenient and 
25 secure delivery to consumers. 
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Figure 1 is a schematic diagram illustrating the topology of one 
embodiment of the electronic invoice delivery system of the present invention. 

Figure 2 is a block diagram illustrating the process for adding a biller to 
me universal biller file for one embodiment of the present invention, 



Figure 3 is a schematic diagram illustrating the data flow in a customer 
S 10 recuesttransactionforoneembodimentofthepresentinvention. 
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Figure 4 is a block diagram Ulustraung a customer request transaction for 
S one embodiment of the present invention. 

g 15 Figure 5 is a block diagram Ulustraung a customer activation request 

1 transaction for one embodiment of the present invention. 

Figure 6 illustrates Type I invoice presentation ih one embodiment of the 

present invention. 

. Figure 7 is an Ulustration of a Type I invoice of one embodiment of the 
present invention. 

Fi ^e 8 mu Stt a te sT y pen 1 nvo i ce P r eSe n« a o„i„o„e em bod ta ,en.o. t h e 
25 present invention. 
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Figure 9 is an illustration of a Type II invoice of one embodiment 
present invention. 



Figure 10 illustrates Type III invoice presentation in one embodiment of 

5 the present invention. 

Figure 11 is a block diagram illustrating a customer change in type of 

* invoice request transaction for one embodiment of the present invention. 

O - 

O 10 Figure 12 is a block diagram illustrating a customer change personal 

S information request transaction for one embodiment of the present invention. 
0} 

□ • 

5t Figure 13 is a block diagram illustrating a customer request for 

U deactivation of service for one embodiment of the present invention. 

0 15 

2 Figure 14 is a block diagram illustrating a request for changing the 

01 invoice destination node for one embodiment of the present invention. 



• invoice 



Figure 15 is a block diagram illustrating a customer change paper ] 
20 delivery option request transaction for one embodiment of the present invention. 

Figure 16 is a block diagram illustrating a customer request for Type I or 
Type H replacement invoice transaction for one embodiment of the present 



invention. 
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Figure 17 is a block diagram illustrating a customer request for Type III 
replacement invoice transaction for one embodiment of the present invention. 

8 Express Mail #EM300602468US 

95000.952 



Figure 18 is a block diagram illustrating a customer request for a paper 
copy of an invoice transaction for one embodiment of the present invention. 

5 Figure 19 is a block diagram illustrating a biller confirmation of a 

customer service request transaction for one embodiment of the present 
invention. 

Figure 20 is a block diagram illustrating a biller notification of change in 
10 UBF option transaction for one embodiment of the present invention. 

Figure 21 is a block diagram illustrating a biller deactivation of customer 
account transaction for one embodiment of the present invention. 



15 



Figure 22 is a block diagram illustrating a CH/SP invoice undeliverable 
notification to biller transaction for one embodiment of the present invention. 



Figure 23 is a block diagram illustrating a CFI/SP notification of invoice 
non-delivery transaction for Type I and Type II invoice delivery for one 
20 embodiment of the present invention. 

Figure 24 is a block diagram illustrating a system manager notification of 
invoice non-delivery transaction for Type III invoice delivery for one 
embodiment of the present invention. 

25 
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Figure 25 is a block diagram illustrating a CFI/SP positive confirmation of 
invoice delivery transaction for Type I and Type II invoice delivery for one 
embodiment of the present invention. 

Figure 26 is a block diagram illustrating a system manager positive 
confirmation of invoice delivery transaction for Type III invoice delivery for one 
embodiment of the present invention. 

Figure 27 is a schematic diagram of an example computer system that can 
be used for a customer, biller, bank, or system manager computer system of the 
present invention. 
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DETAILED DESCRIPTION HE THB INVENTION 



In the following description, numerous specific details are set forth in 
order to provide a thorough understanding of the present invention. It will be 
5 apparent to one skilled in the art, however, that the present invention may be 
practiced without these specific details. In other instances, well-known features 
have not been described in detail in order not to unnecessarily obscure the 
present invention. 

10 Figure 1 shows the topology of one embodiment of the electronic invoice 

presentation (ETP) system of the present invention. As shown in Figure 1, this 
embodiment includes a biller 100, a biller bank 110, a transport network 120, a 
customer bank 130, a customer 140, and a system manager 150. Biller 100 may 
be any of a variety of entities that provide products or services to customer 140. 
15 Examples of entities that may be a biller 100 include utility companies, mortgage 
banks, credit card companies, etc Biller bank 110 is a bank that provides EIP 
services to biller 100. Biller bank 110 may also provide electronic bill payment 
services to biller 100. Transport network 120 is a secure data communications 
network, such as for example the VisaNet(TM), that is used to pass messages 
20 between biller bank 110 and customer bank 130. Transport network 120 may 
also provide additional system functions, including message verification and 
database maintenance. Customer bank 130 is a bank or other service provider 
that provides EIP services to customer 140. Customer bank 130 is also referred 
to herein as a CFI/SP (Consumer Financial Institution or Service Provider). 
25 CFI/SP 130 may also provide electronic bill payment services to customer 140. 
Customer 140 is any entity that is a customer of biller 100. System manager 150 
performs a variety of system management operations to insure proper operation 
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of an EIP system. System manager 150 may, for example, be an entity that owns 
transport network 120 and that provides access to biller banks and CFI/SP to an 
EIP system. In one embodiment of the invention, the system manager is Visa 
International. 

5 

Also included in the embodiment of Figure 1 is a Universal Biller File 
J (UBF) 160. UBF 160 is a control file containing key information about all billers 
H participating in the electronic invoice presentation system of Figure 1. UBF 160 
|j contains information about billers provided to system manager 150 by the 

? 10 billers. UBF 160 is used to identify billers, to communicate biller service options, 

=sesr 

gj to perform process edits on data transported between a CSI/SP and a biller, and 

O to support CFI/SP service packaging. UBF 160 is maintained by system 

5 manager 150. Updated copies of UBF 160 are periodically distributed by system 

N= manager 150 to the CFI/SP's including CH/SP 130. 
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The particular information contained in a UBF varies according to the 
specific embodiment of the invention, but in general includes all the biller 
information needed by CFI/SP's and the system manager for proper operation of 
an EIP system. For example, in one embodiment of the present invention, the 
20 UBF includes the following entries for each biller: 
Biller name. 
Biller address(es). 

Biller unique identification number (UID). 
Biller account number format. 
25 Biller invoice formats. 

EIP service options supported by biller. 
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The biller name and biller address entries contain the toiler's name and 
address as supplied by the biller. The biller unique identification number is a 
number assigned by the system manager. The biller account number format is 
supplied by the biller and indicates the format used by the biller for customer 
5 account numbers. The biller invoice format entry is supplied by the biller and 
specifies the format for the electronic invoices of the biller. This entry may, for 
| example, include an invoice template containing data fields for monthly invoice 

2 data, as well as static material that is included with each invoice. The EIP 
| service options supported by biller entry is supplied by the biller and indicates 
§ 10 which EIP service options the biller supports. 

rd 

50 

O In one embodiment of the invention, EIP service options include: 

IH Invoice type option. 

H- Paper invoice delivery option. 

O 

O 15 On-demand paper invoice delivery option. 

£ Personal information change option. 

m Positive confirmation of invoice delivery option. 

In one embodiment of the invention, there are three invoice type options, 
20 designated "Type I", "Type II", and 'Type III", respectively. 

The Type I invoice delivery option supports limited data summary 
invoices only, and does not support any graphics or display instuctions. Type I 
is suited for initial biller implementations and invoice delivery for screen phone, 
touch tone and self-service invoice delivery devices. In this option, the biller is 
allowed to send a predetermined number of pre-defined data elements via the 
biller'sbankandthetransportnetworktoacertifiedCn/SP. Inone 
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embodiment, this predetermined number is 23. A certified CFI/SP is a CFI/SP 
that has met the system manager's security and other criteria, including 
processing, audit, and liability requirements, for handling sensitive customer 
billing information. In Type I invoice delivery the biller sends the invoice data 
to the biller bank. The biller bank forwards it via the transport network and the 
system manager to the certified CFI/SP. The CFI/SP holds the data until 
presented to the customer. When presented to the customer, the CFI/SP formats 
the data for display, using the invoice format for the biller specified in the UBF 
and the current dynamic customer data received from the biller. 

Figure 6 illustrates Type I invoice presentation in one embodiment of the 
present invention. As shown in Figure 6, in this embodiment, biller 100 sends 
biller bank 110 invoice data for the invoice being presented. Biller bank 110 
sends the invoice data via transport network 120 to system manager 150. System 
manager 150 checks to make sure the invoice data is properly formatted, and 
sends the invoice data via transport network 120 to certified CFI/SP 600. 
Certified CH/SP 600 formats the data for display on the customer's delivery 
device and presents the data as a limited summary without graphics to customer 
140. 

Figure 7 is an illustration of a summary bill of one embodiment of the 
present invention as may be displayed on a customer's delivery device. The 
summary bill data includes the biller's name 705, the customer's account number 
715, the customer's name and address 725, a listing of current and previous 
charges 735, an explanation of current charges 745, and a return address 755. 
The summary information corresponds to the information that is normally 
included on the remittance stub of a mailed, paper bill. 
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Type II invoice delivery supports both summary data invoices and fuH 
detail invoices and support biller defined coior and graphic, .n Type.II invoice 
delivery, the biller, or the biller bank, creates an invoice template. The template, 
5 which may include color graphics, contains fields for customer specific invoice 
data The template may also include static materials, such as marketing graph.cs 
i andtext. The template is stored in the biller invoice format entry of the UBF. 
% ThebiUersendsdynamiccurrentinvoicedauforacusvomerWmebulerbank. 

t This invoice data is the data for the customer mat isspecific to the current bill. 

0 10 HorTO mple,f.r m e,ectncu^biU.mecurre„.invoicedatamayinc.udem, 
S aatesofusagecoveredbymebill.theusageamoun.theamountofmelas. 

1 payment.thecurrentamountdue.etc. The biller bank sends mecurrentinvo.ee 
S da^viaftetrar.por.network.ndsys^mm.nagertomecusu.mer-sce^ed 
I. cm/SP.TheCfT/SPassemblesaninvoicebyretnevingmebffler'sinvo^ 

I 15 templa.efrommeCH/SP'scopyofme^Fandmergingthereceivedinvo.ce 
1 data. The CT1/SP holds the invoice until it is delivered to the customer. 

Whether or not the detailsand graphics included in a Type il invoice are , 
acmall, viewed by a customer depends on the type of dehvery device used by 
» mecustomertoaccessdveinvoice. If the corner uses a Worming- dev.ee, 
mec us.omerwillreceive,hefuubulde*. An example o, a con<ormmg 
deviceisaperson^computerwithacolormoni^r. If the customer uses a n m - 
inning" dev,ce.however,me— - only ob U m summary mvo.ee 
data. An example o, a non-conforming device is a touch-tone phone. 

BgureSillustratesTypeUmvoicepresenudoninoneembodimentofme 
present—. mausembodiment.asshowninF.gureS.b.UenOOsends 
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invoice data to biller bank 110. Biller bank formats the invoice data in the 
manner required by transport network 120 and sends the invoice data via 
transport network 120 to system manager 150. System manager 150 checks the 
invoice data for proper format, and sends the invoice data via transport network 
120 to certified CFI/SP 600. Certified CH/SP 600 assembles an invoice by 
retrieving the toiler's invoice template from CFI/SP's 600 copy of UBF 160 and 
merging the received invoice data into the appropriate fields of the invoice 
3 template. CH/SP 600 holds the invoice until it is delivered to the customer 140. 

|j The invoice may be delivered to the customer either in the form of summary 

10 data or as detailed data with full graphics depending on the delivery device 
used by customer 140 and the customer's indicated bill type preference. If a 
j| biller supports Type II invoice presentation, the customer may request delivery 
of either a summary or detailed bill in its service activation request. 

o 

O 15 Figure 9 is an illustration of a detailed bill of one embodiment of the 
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present invention as may be displayed on a conforming delivery device. Like 
summary invoice 700 of Figure 7, detailed invoice 900 of Figure 9 includes the 
biller's name 705, the customer's account number 715, the customer's name and 
address 725, a listing of current and previous charges 735, an explanation of 

20 current charges 745, and a return address 755. In addition, detailed invoice 900 
includes additional details and graphics, including a logo 950, a graph showing 
a comparison of present and previous monthly electricity use 910, a energy 
conservation message 920, and advertisements 930 and 940. Detailed invoice 900 
in general may contain such detail as allows a biller to completely replace the 

25 biller's mailed paper bill with electronic detailed invoice 900. 
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Detailed invoice 900 contains items from the biller's invoice template, 
dynamic current invoice data, and static invoice data. Items from the biller's 
invoice template include the biller's name 705, return address 755, and logo 950. 
In addition, the locations for the remaining items are specified by the invoice 
5 template. Of the remaining items, customer account number 715, customer 
name and address 725, current and previous charges 735, explanation of current 
charges 745, and detailed history of energy use 910 constitute dynamic current 
invoice data for the customer. Energy conservation message 920 and 
advertisements 930 and 940 may each constitute static invoice data or dynamic 
| 10 current invoice data, depending on whether an item is included in all customer 
« invoices (in which case the item constitutes static invoice data) or whether an 
1 item is specifically selected for the customer, for example based on the 

I ■ customer's demographics (in which case the item constitutes dynamic current 
U invoice data). Static invoice data is changed by the biller by updating the biUer's 
5 15 invoice template in the UBF. 
<q 

m Type ffl invoice presentation is applicable when the customer's CH/SP is 

a non-certified CFI/SP. Because the customer's CH/SP is not certified, it is not 
authorized to handle the customer's confidential billing information. Instead, 
20 the invoice is held by the system manager. The customer receives a message 
from the customer's non-certified CH/SP indicating that a bill has arrived. The 
customer then contacts the system manager directly to obtain a copy of the bill. 
Type ffl invoice presentation supports detailed and summary invoices. 

Figure 10 illustrates Type ffl invoice presentation in one embodiment of 
the present invention. In this embodiment, as shown in Figure 10, biller 100 
sends invoice data to biller bank 110. Biller bank 110 sends the invoice data via 
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transport network 120 to system manager 150. System manager 150 checks the 
invoice data for proper format. If the format is proper, system manager 150 
retrieves the biller's invoice template from the system manager's copy of UBF 160 
and assembles an invoice using the biller's invoice template and the invoice data 
5 received from biller bank 110. System manager 150 sends a notice of the waiting 
invoice via transport network 120 to non-certified CFI/SP 1000. Non-certified 
CFI/SP 1000 passes on the notice of the waiting invoice to customer 140. To 
receive the invoice, customer 140 sends a request, for example via a dial-up 
modem connection, to system manager 150. System manager 150 validates the 
10 customer's identity, for example using a password and/or PIN number system. 
Once the customer's identity has been validated, system manager 150 conveys 
the invoice to customer 140. System manager 150 may use the same dial-up 
connection used by customer 140 to transmit the invoice to customer 140, or the 
. may be presented to the customer on another display device. 
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If a biller supports Type m invoice delivery, the customer may request 
either detailed or summary invoices. 

One embodiment of the present invention includes the following paper 
20 bill delivery options that a biller may specify in the UBF: 
Biller always mails paper invoice. 
Biller never mails paper invoice. 

Biller will activate paper invoice delivery on customer's request. 
Biller will cease paper invoice delivery on customer's request 

25 
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One embodiment of the present invention requires the biller to deliver 
paper invoices together with electronic invoices, regardless of paper bill delivery 
option chosen, for the first three month's of EIP service. 

One embodiment of the present invention includes two on-demand paper 
bill delivery options that a biller may specify in the UBF: 
Biller supports option. 
Biller does not support option. 
3 if the biller supports the on-demand paper bill delivery option, the biller agrees 
10 to send a complete paper invoice to a customer upon demand. 
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I one embodiment of the present invention includes two personal 

| information change options that a biller may specify in the UBF: 

L Biller allows electronic change of a customer's personal information. 

| 15 - Biller does not allow electronic change of a customer's personal 

5 information. 

One embodiment of the present invention includes three confirmation of 
invoice delivery options that a biller may specify in the UBF: 
20 Biller supports option for all customers. 

Biller supports option for specified customers only. 

Biller does not support option. 
If the biller supports a confirmation of invoice delivery for a customer, the 
CFI/SP is required to confirm to the biller each invoice delivery to a customer. 
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Figure 2 is a block diagram of the process used to add a new biller to the 
UBF in one embodiment of the present invention. As shown in Figure 2, the 
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process begins when the biller fills out a biller questionnaire at block 200. The 
biller files the questionnaire with the biller bank at block 210, and the biller bank 
conveys the biller data contained in the biller questionnaire to the system 
manager at block 220. The system manager adds the new biller data to the UBF 
5 at block 230, and distributes the updated UBF to the CFI/SFs at block 240. The 
distribution at block 240 may occur at regular intervals, or whenever the system 
C manager believes the amount of changes made to the UBF warrants distribution 

III 

^ of an updated version of the UBF. 
H 

O 

S 10 In addition to the UBF, other components of the electronic invoice 

| presentation (EIP) system of the present invention include a set of control and 
maintenance transactions, and an invoice delivery system. 
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The set of control and maintenance trancsactions allows CFI/SFs and 
billers to control and maintain the EIP service. The transactions occur according 
| to a set of pre-defined rules. These rules ensure that the EIP service performs 
* with certainty and flexibility. The transactions control such functions as service 
activation, service deactivation, and maintenance of the service structure. 
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Figures 3 and 4 illustrate a customer service request transaction of one 
embodiment of the present invention. A customer service request includes any 
request from a customer related to the EIP system. Examples of customer service 
requests in one embodiment of the invention include: 

A customer activation request 

A customer request for a change in type of invoice. 

A request to change a customer's personal information. 

A customer request to deactivate service. 
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A request to change the invoice destination node. 

A customer request to change a paper invoice delivery option. 

A customer request for a replacement invoice. 

A customer request for a paper copy of an invoice. 

5 

As shown in Figures 3 and 4, a customer service request transaction 
originates when a customer 140 conveys a request for service to CFI/SP 130. 
This step is indicated by the number 1 in Figure 3 and as block 400 in Figure 4. 
CFI/SP 130 formats the request in the manner required by transport network 120 
10 and transmits it via transport network 120 to system manager 150. This step is 
indicated by numbers 2 and 3 in Figure 3 and block 410 in Figure 4. As shown 
Figure 4, after receiving the request, system manager 150 checks to see if the 
quest is proper at block 430. A proper request is onethat is properly 
formatted, that comes from a participant CFI/SP, that relates to a participant 
15 biller, and that requests a type of service that the biller provides. 

If the request is not a proper request, system manger 150 sends CFI/SP 
130 an error message at block 440. 
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If the request is proper, system manager 150 sends the request to biller 
bank 110 via transport network 120 at block 450. This step is also indicated by 
numbers 4 and 5 in Figure 3. Biller bank 110 in turn conveys the request to biller 
100. This step is indicated by number 6 in Figure 3 and block 460 in Figure 4. • 

The method steps shown in 4 apply generally to any customer service 
request transaction. For specific types of transactions, the method steps may 
include transaction-specific details. 
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Figure 5 is a block diagram illustrating a customer activation request 
transaction for one embodiment of the present invention. As shown in Figure 5, 
a customer initiates activation of an electronic invoice presentation service from 
a specified biUer by sending the customer's CH/SP a request for activation of 

EIP service at block 500. The request specifies the biller with whom the 
customer wishes to activate service, the customer's account number with the 
% biller, and the invoice delivery option the customer wishes to receive. After the 
| customer's CH/SP receives the customer's request for EIP service activation, the 

S io CH/SP formats the request for transmission via the secure transport network to 
1 the system manager. In one embodiment, the format used is the "VIP SMS" 

format. In another embodiment, the format used is the "BASE n TC50" format. 
In one embodiment, the information contained in the request for service 
U activation transmitted to the system manager by the CH/SP includes: 

b 

p 15 Invoice type. 

Invoice destination node. 
y % Paper invoice option. 

Delivery method (Type II or III only) 

PIN /password (Type III only) 
20 Device type. 

The invoice type indicates which type of invoice delivery will be used. In 
this embodiment, the invoice types are Type I, Type H, and Type III as described 
with respect to Figures 6-10. The invoice type selected must be an invoice type 
25 supported by the applicable biller. 



m 

o 

Ul 



22 Express Mail #EM300602468US 

95000.952 



The invoice destination node is the node that will hold the invoice for 
presentation to the customer. For Types I and II, the invoice destination node is 
the cusomer's certified CFI/SP. For Type IE, the invoice destination node is the 
system manager. 

5 

The paper invoice option indicates which paper invoice delivery option 

£ the customer desires. The paper invoice option selected must be an option that 

HI 

is supported by the biller. 

O 

S 10 The delivery method indicates whether the customer wishes to receive 

S summary invoice data, a detailed invoice, or both. This information is only 

1 needed if the invoice type is Type II or Type III. For.Type I there is no choice, 

\h only summary invoice data is available. 



O 



15 



20 



The PIN/password entry specifies the PIN and or password that the 
customer will use to obtain an invoice from the system manager. This entry is 
only used for Type ID invoice delivery. 

The device type entry indicates which device type, conforming or non- 
conforming, will be used by the customer to display electronic invoices. 

As shown in Figure 5, the CFI/SP formats the service request and sends it 
via the transport network to the system manager at block 510. The system 
manager revives the request and checks it for form and content at block 520. 

For example, the system manager checks that the request is formatted in the 
proper format required to transmit it via the transport network, checks to make 
sure the biller specified is a participant in the EIP system, and compares the 

23 Express Mail #EM300602468US 

95000.952 " * 



service options specified in the request to the service options supported by the 
biller as specified in the UBF. 

If the request is found to be improper at block 530, the system manager 
5 sends the CFI/SP an error message at block 540. An example of an improper 
request is a request for a service option not supported by the applicable biller. 

3 If the request is found to be proper at block 530, the system manager 

g sends the request on to the biller bank, via the transport network, at block 550. 
S 10 ThebiUerbankconveystherequesttothebiUeratblockSeO-Thebillerupdates 

™ the billet's database to reflect activation of service by the customer, and stores 
1 thecustomer-sservice P referencesatblock570. The biller sends a confirmation 
I of receipt of the service activation request to the CFI/SP, via the biller bank and 
transport network, at block 580. 

Figure 11 is a block diagram illustrating a customer change in type of 
invoice request transaction for one embodiment of the present invention. This 
type of transaction is available only if the biller supports the new type of invoice 
the customer is requesting. As shown in Figure 11, this type of transaction 
begins when a customer conveys a request for a change in the invoice type 
delivered by a particular biller to the customer's CFI/SP at block 1100. The 
CFI/SP formats, the request (for example as a VIP SMS formatted or BASE II 
TC50 formatted transaction) and sends it via the transport network to the system 
manager atblock 1110. The system manager checks the request for proper form 
and content (including biller support of the invoice type requested) at block 
1120 If the system manager finds the request improper at block 1130, the system 
manager sends the CFI/SP an error message at block 1140. If the request is 
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proper, the system manager sends the request via the transport network to the 
biller bank at block 1150. The biller bank conveys the request to the biller at 
block 1160. In one embodiment, the biller bank is required to convey the request 
to the biller within two days of receipt. The biller updates the biller's database 
5 with the customer's new preference at block 1170, and sends a confirmation via 
the transport network to the CFI/SP at block 1180. 

Figure 12 is a block diagram illustrating a customer change personal 
information request transaction for one embodiment of the present invention. 
10 This type of transaction is available only if the biller supports the option of 

allowing changes in a customer's personal information by electronic means. As 
shown in Figure 12, this type of transaction begins when a customer conveys a 
request for a change in personal information to the customer's CFI/SP at block 
1200... The CFI/SP formats the request (for example as a VIP SMS formatted or 
15 BASE II TC50 formatted transaction) and sends it via the transport network to 
the system manager at block 1210. The request includes, as applicable, the 
former and present values of the customer billing address, the customer last 
name, and the customer phone number. The system manager checks the request 
for proper form and content, including checking whether the biller supports 
20 electronicch a ngesincustomerpersonalinformation,atblockl220. Ifthesystem 
manager finds the request improper at block 1230, the system manager sends the 
CFI/SP an error message at block 1240. If the request is proper, the system 
manager sends the request via the transport network to the biller bank at block- 
1250 The biller bank conveys the request to the biller at block 1260. In one 
25 embodiment, the biller bank is required to convey the request to the biller withm 
two days of receipt. The biller updates the biller's database with the customer's 
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personal information at block 1270, and sends a confirmation via the 
transport network to the CFI/SP at block 1280. 



new 



Figure 13 is a block diagram illustrating a customer request for 
5 deactivationofserviceforoneembodimentofthepresentinvention. X customer 
may request this type of transaction, for example, if the customer is terminating 
- service with a specific biller of with a CFI/SP. As shown in Figure 13, this type 
% of transaction begins when a customer conveys a request for deactivation of 

0 service to the customer's CFI/SP at block 1300. The CFI/SP formats the request 
S 10 (forexampleasaVIPSMSfonnattedorBASE^^ 

S and sends it via the transport network to the system manager at block 1310. The 
system manager checks the request for proper form and content at block 1320. If 
the system manager finds the request improper at block 1330, the system 
jj, ma nag e r S end S theCH/SPanerrormes S ageatblockl340.Iftherequestis 
S 15 proper^esystemma^agersendsmerequestviametransportnetworktothe 

1 biller bank at block 1350. The biller bank conveys the request to the bxller at 
" block 1360. in one embodiment, the biller bank inquired to convey the request 

tothebillerwithintwodaysofreceipt The biller deactivates the customer from 
the biller-s EIP service at block 1370, and sends a confirmation via the transport 
20 network to the CFI/SP at block 1380. 

Figure 14 is a block diagram illustrating a request for changing the 

invoice destination node for one embodiment of the present invention. A 
CH/SPma y r e questthistype 0 ftransaction,forexam P le,whentheCH/SP - 

25 changesthemvoicedestinationnodeinternally. This may oca*, for example 
toa notherdeliverydevice(e.g.apersonalcomputer).AsshowninH g urel 4 , 
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this type of transaction begins when a CFI/SP generates a request for a change of 
destination node, formats the request (for example as a VIP SMS formatted or 
BASE II TC50 formatted transaction) and sends it via the transport network to 
the system manager at block 1410. The system manager checks the request for 
5 proper form and content at block 1420. If the system manager finds the request 
improper at block 1430, the system manager sends the CFI/SP an error message 
at block 1440. If the request is proper, the system manager sends the request via 
the transport network to the biller bank at block 1450. The biller bank conveys 
the request to the biller at block 1460. In one embodiment, the biller bank is 
10 required to convey the request to the biller within two days of receipt. The biller 
updates the biller's database to reflect the new invoice destination node at block 
1470, and sends a confirmation via the transport network to the CFI/SP at block 
1480. 

15 Figure 15 is a block diagram illustrating a customer change paper invoice 

delivery option request transaction for one embodiment of the present invention. 
This type of transaction is available only if the biller supports the paper invoice 
delivery option to which the customer wishes to change. As shown in Figure 15, 
this type of transaction begins when a customer conveys a request for a change 

20 inpaperinvoicedeliveryoptiontothecustomer'sCFI/SPatblocklSOO. The 

CFI/SP formats the request (for example as a VIP SMS formatted or BASE II 
TC50 formatted transaction) and sends it via the transport network to the system 
numager at block 1510. The system manager checks the request for proper form 
and content, including checking whether the biller supports the new paper 
25 invoice delivery option, at block 1520. If the system manager finds the request 
unproper at block 1530, the system manager sends the CFI/SP an error message 
at block 1540. If the request is proper, the system manager sends the request vxa 
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the transport network to the biller bank at block 1550. The biller bank conveys 
the request to the biller at block 1560. In one embodiment, the biller bank is 
required to convey the request to the biller within two days of receipt. The biller 
updates the biller's database with the customer's new paper invoice delivery 
preference at block 1570, and sends a confirmation via the transport network to 
the CFI/SP at block 1580. 

Figure 16 is a block diagram illustrating a customer request for Type I or 
Type II replacement invoice transaction for one embodiment of the present 
invention. A customer may make such a request, for example, if the customer 
has lost or damaged the original invoice and needs another copy. In one 
embodiment of the present invention, for Type I and Type II invoice delivery, 
the CH/SP is required to store copies of electronic invoices for a specified period 
of time after delivery to the customer. In one embodiment, this period of time is 
one billing cycle. As shown in Figure 16, this type of transaction begins when a 
customer requests a replacement invoice from the customer's CFI/SP at block 
1600. In the request, the customer includes a unique invoice ID that identifies 
the invoice for which the customer wishes to receive a replacement The CFI/SP 
retrieves the invoice identified by the unique invoice ID and delivers a 
replacement copy to the customer at block 1610. 

Figure 17 is a block diagram illustrating a customer request for Type III 
replacement invoice transaction for one embodiment of the present invention. In 
one embodiment of the present invention, for Type III invoice delivery, the 
system manager stores copies of electronic invoices for a specified period of time 
after delivery to the customer. In one embodiment, this period of time is 
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one billing cycle. As shown in Figure 17, this type of transaction begins when a 
customer requests a replacement invoice from the system manager at block 1700. 
In the request, the customer includes a unique invoice ID that identifies the 
invoice for which the customer wishes to receive a replacement as well as the 
customers PIN and/or password. The system manager verifies the PIN and/or 
password of the customer, and retrieves the invoice identified by the unique 
invoice ID and delivers a. replacement copy to the customer at block 1710. 

Figure 18 is a block diagram illustrating a customer request for a paper 

0 10 copy of an invoice transaction for one embodiment of the present invention. 

1 This type of transaction is avaUable only if supported by the biller. A customer 
1 may request a paper copy of a bill if the customer needs more detail than 

I . provided by a summary invoice or if the customer needs an invoice for receipt 
U purposes. As shown in Figure 18, this type of transaction begins when a 
| 15 customer conveys a request for a paper copy of a specific biller's invoice to the 
S customer's CFI/SP at block 1800. The request includes a unique invoice 
* identification number. In one embodiment of the invention, the request must be 
made within two billing cycles of the original invoice date. The CFI/SP formats 
the request (for example as a VIP SMS formatted or BASE II TC50 formatted 
20 transaction) and sends it via the transport network to the system manager at 

block 1810. The system manager checks the request for proper form and content, 
including checking whether the biller supports paper invoice delivery, at block 
1820. If the system manager finds the request improper at block 1830, the system 
manager sends the CFI/SP an error message at block 1840. If the request is 
25 proper^esystemmanagersendsmerequ^t^ametransportnetworktothe 

biller bank at block 1850. The biller bank conveys the request to the biller at 
block 1860. In one embodiment, the biller bank is required to convey the request 
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to the biller within two days of receipt. The biller produces the paper bill and 
sends it to the customer at block 1870, and sends a confirmation via the transport 
network to the CFI/SP at block 1880. In one embodiment of the invention, the 



5 a customer frequently requests paper copies of invoices. 

In one embodiment of the present invention, biller request /confirmation 
control and maintenance transaction types include: 
Biller confirmation of service request. 



customer service request transaction for one embodiment of the present 
15 invention. In one embodiment of the present invention, biller confirmation i 
mandatory for the following service requests: 

Customer activation of service. 

Invoice Type change. 



biller may impose permanent delivery of paper bills, instead of electronic bills, if 



10 



Biller notification of change in UBF option. 
Biller deactivation of a customer account. 



Figure 19 is a block diagram illustrating a biller confirmation of a 



20 



Change in customer personal information. 
Customer request for a paper copy of invoice. 
Change in paper invoice delivery option. 
Change of invoice destination node. 
Customer requested deactivation. 
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confirmation includes particulars of the service requested. The biller bank 
formats the confirmation (for example as a BASE II TC50 formatted transaction) 
and sends it via the transport network to the system manager at block 1920. In 
one embodiment of the invention, the biller bank must send the confirmation to 
5 the system manager within five days of receiving the original service request 
from the system manager. The system manager checks the confirmation for 
proper form and sends the confirmation via the transport network to the 
customer's CFI/SP at block 1930. The customer's CFI/SP conveys the 
confirmation to the customer at block 1940. In one embodiment, the CFI/SP 
need not convey the confirmation to the customer if the service request was for a 
change in invoice destination node or a customer requested deactivation. 



10 



Figure 20 is a block diagram illustrating a biller notification of change in 
UBF option transaction for one embodiment of the present invention. As shown 
15 in Figure 20, this type of transaction begins when a biller changes one or more 
UBF options at block 2000. The biller generates a change in UBF options notice 
for each affected customer and sends the notice to the.biller bank at block 2010. 
The notice includes particulars of the UBF option change. The biller bank 
formats the notice (for example as a BASE H TC50 formatted transaction) and 
20 sends it via the transport network to the system manager at block 2020. In one 
embodiment of the invention, the biller bank must send the notice to the system 
manager within two days of receiving the notice from the biller. The system 
manager checks the notice for proper form and sends the notice via the transport 
network to the customer's CFI/SP at block 2030. The customer's CFI/SP conveys 
25 the notice to the customer at block 2040. In one embodiment, the CFI/SP must 
convey the notice to the customer within one day after receiving it 
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Figure 21 is a block diagram illustrating a biller deactivation of customer 
account transaction for one embodiment of the present invention. A biller may 
deactivate a customer's account if the customer terminates its relationship with 
the biller (e.g. the customer pays off a loan), if the biller ceases to provide the 
service the customer was receiving, if the customer abuses electronic invoicing, 
or for some other reason. As shown in Figure 21, this type of transaction begins 
when a biller generates a notice of deactivation of a customer's account at block 
2100. In one embodiment of the present invention, the deactivation notice must 

0 be sent by the biller to the biller bank within 1 day after a customer termination. 
S 10 In one embodiment, the notice must include the reasons for the deactivation. 

1 The biller bank formats the deactivation notice (for example as a BASE II TC50 
1 formatted transaction) and sends it via the transport network to the system 

| manager at block 2110. In one embodiment of the invention, the biller bank 

I must send the deactivation notice to the system manager within two days of 

S 15 receiving the notice from the biller. The system manager checks the notice for 
I proper form and sends the notice via the transport network to the customer's 
* CFI/SP at block 2120. The customer's CFI/SP updates its database to reflect the 

customer deactivation at block 2130, and conveys the deactivation notice to the 
customer at block 2140. In one embodiment, the CH/SP must convey the notice 
20 to the customer within one day after receiving it 

in one embodiment of the present invention, CFI/SP notification control 
and maintenance transaction types include: 

CFI/SP invoice undeliverable notification to biller. 
CFI/SP invoice non-delivery notification to biller (Types I and II). 
System manager invoice nondelivery notification to biller (Type ffl). 
CFI/SP positive invoice delivery confirmation to biller (Types I and II). 
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System manager positive invoice delivery confirmation to biller (Type III) . 

Figure 22 is a block diagram illustrating a CFI/SP invoice undeliverable 
notification to biller transaction for one embodiment of the present invention. 
5 Such a notification arises when a CFI/SP receives an invoice that it cannot 
deliver to a customer, because, for example, the customer is not on file with the 
CFI/SP. The biller therefore must be notified that the invoice has been sent to a 

V! 

2 wrong destination. As shown in Figure 22, this type of transaction begins when 

^ a CFI/SP receives an invoice that it cannot deliver at block 2200. The CFI/SP 

Si 

g 10 generates an invoice undeliverable notification at block 2210. The notification 

5 includes the reason why the invoice is undeliverable. The CFI/SP formats the 

CO v 
O notification (for example as a VIP SMS or BASE n TC50 formatted transaction) 

S and,sends it via the transport network to the system manager at block 2220. In 

U one embodiment of the invention, the CFI/SP must send the undeliverable 

15 notification to the system manager within one day after the CFI/SP discovers 
that the invoice is undeliverable. The system manager checks the notification for 
proper form, including insuring that the biller to whom it is addressed is a 
participant in the EIP system, at block 2222. If the notification is not of proper 
form, the system manager sends the CFI/SP an error message at block 2225. If 
20 the notification is of proper form, the system manager checks if the notification 
relates to a Type III invoice delivery option at block 2230. If the notification 
relates to a Type ffl invoice delivery option, the system.manager deletes the 
undeliverable invoice from its invoice storage at block 2240. The system 
manager sends the notification via the transport network to the biller bank at 
25 block 2250. The biller bank conveys the undeliverable notification to the biller at 
block 2260. In one embodiment, the biller bank must convey the notification to 
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the biller within two days after receiving it. The biller updates its database 
the undeliverable status of the invoice at block 2270. 



Figure 23 is a block diagram illustrating a CFI/SP notification of invoice 
5 non-delivery transaction for Type I and Type II invoice delivery for one 

embodiment of the present invention. For Type I and Type H invoice delivery, 
the customer's certified CFI/SP is responsible for delivery of the invoice to a 
customer. A CFI/SP sends a notification of invoice non-delivery to a biller if the 
invoice due date has passed without the customer receiving the invoice. The 
10 customerm a ynothaverec e ivedtheinvoicebecause,forexam P le,thecustomer 

did not access the device over which the invoice is delivered to the customer. As 
shown in Figure 23, this type of transaction begins when an invoice delivery 
date passes without the invoice having been, delivered to the customer at block 
2300. The customer's CFI/SP generates an invoice non-delivery notification at 
15 block* 2310. The CFI/SP formats the notification (for example as a VIP SMS or 
BASE II TC50 formatted transaction) and sends it via the transport network to 
the system manager at block 2320. In one embodiment of the invention, the 
CFI/SP must send the invoice not delivered notification to the system manager 
within one day after the invoice due date: The system manager checks the 
20 notification for proper form, including insuring that the biller to whom it is 

addressed is a participant in the EIP system, at block 2330. If the notification is 
not of proper form, the system manager sends the CFI/SP an error message at 
block2340. Ifthenotificationisofproperform,thesy S temman a ger S endsthe 
notmcationviametransportnetworktomebmerbankatblock2350.ThebiIler 
25 fcank c O nveysthen O n-deliverynotificationto t h e billeratblock2360. Inone 

embodiment, the biller bank must convey the notification to the biller within two 
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days after receiving it The biUerupdaiesteda.abasewi* the invoice non- 
delivery (or bill not read) status at block 2370. 

Figure 24 is a block diagram illustrating a system manager notification of 
invoice nondelivery transaction for Type III invoice delivery for one 
embodimentofftepresentmvention. For Type m invoice delivery, the 
customer's non-eerufied CF1/SP deliver, a notice of waiting invoice to the 

tnecustomer. The system manage, sends a notion o, invoice non-del.v«y 
toabmerifuneinvoiceduedatebaspassedwimoutme^tomerrec.v.ngtne 

ta v„ic. Tnecustomermayno.Kaverecei.dUreinvoic.because, orexampl. 
n d.e — didnotaccessmedeviceoverwmcbmemvoiceisdel.eredto^e 

1 customer. 

g „ _atb,ock 2 «0.r„es y stemm». g ergenera^.nmvo ; ce»on-de^ 
S exampleasaVXPS^orBASEnrCSO^Hed.ransacdon.and^J 

20 UbiUer Jkwitninonedayaftertbeinvoiceduedate. Theillerbar* 
, n .n„n-deliver y nonncadontott,ebiller».block2430.Inone 
conveys the non deUvery „ ^ biUeI within two 

^bodiment the biller bank must convey the noOncarion to 
embodiment,* iB ^ase v,ifh the invoice non- 

days after receiving it. The bluer upoa 
deUvery (or bill not read) status at block 2440. 
" ^^isab^diagramiilus^gaCm/SPp^veconnrmadonof 
^icedlerytransaceonforType.andTy^n.voic.deliveryforone 
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embodiment of the present invention. A biller may request a CFI/SP to provide 
confirmation of delivery to allow the biller to determine when the customer has 
received an invoice. The biller may make a blanket request that a CFI/SP 
provide confirmation of delivery for all invoices by specifying a confirmation of 
5 delivery option in the biller's entry in the UBF. Alternatively, if the biller wishes 
confirmation of delivery for a specific invoice only, the biller may include a 
9 request for confirmation in the invoice itself when it is sent to the CRI/SP. The 
3 responsible CFI/SP sends a positive confirmation of invoice delivery to a biller 
3 when the customer has downloaded the invoice to a delivery device. As shown 
S 10 in Figure 25, this type of transaction begins when an invoice is delivered to the 
I customer's delivery device at block 2500. The customer's CFI/SP generates an 
D confirmation of delivery notification at block 2510. The confirmation includes 

the date on which the customer received the invoice. The CFI/SP formats the 
notification (for example as a VIP SMS or BASE H TC50 formatted transaction) 
and sends it via the transport network to the system manager at block 2520. In 
one embodiment of the invention, the CFI/SP must send the notification to the 
5 system manager within one day after delivery of the invoice to the customer. 

The system manager checks the notification for proper form, including insurmg 
that the biller to whom it is addressed is a participant in the EIP system, at block 
20 2530. If the notification is not of proper form, the system manager sends the 
CFI/SP an error message at block 2540. If the notification is of proper form, the 
system manager sends the notification via the transport network to the bdler 
bank at block 2550. The biller bank conveys the delivery notification to the taller 
atblock2560. In one embodiment, the biller bank must convey the noufica.on 
25 tothcbillerwithintwodaysafterreceivingit The biller updates its database 
with the invoice delivered status at block 2570. 
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Figure 26 is a block diagram illustrating a system manager positive 
confirmation of invoice delivery transaction for Type III invoice delivery for one 
embodiment of the present invention. A biller may request confirmation of 
delivery to allow the biller to determine when the customer has received an 
invoice. The biller may make a blanket request for confirmation of delivery for 
all invoices by specifying a confirmation of delivery option in the biller's entry in 



J the UBF. Alternatively, if the biller wishes confirmation of delivery for a specific 

invoice only, the biller may include a request for confirmation in the invoice 
J itself when it is sent to the system manager. The system manager sends a 



10 positive confirmation of invoice delivery to a biller when the customer has 

downloaded the invoice to a delivery device. As shown in Figure 26, this type of 



Q 
O 

ru 

m 

O transaction begins when an invoice is delivered by the system manager to the 

U1 customer's delivery device at block 2600. The system manager generates a 

H- confirmation of delivery notification at block 2610. The confirmation includes 

O 

O 15 the date on which the customer received the invoice. The system manager 
yj formats the notification (for example as a VIP SMS or BASE H TC50 formatted 

transaction) and sends it via the transport network to the biller bank at block 
2620. In one embodiment, the system manager must send the delivery 
notification to the biller bank within 1 day of delivery of the invoice to the 
20 customer. The biller bank conveys the delivery notification to the biller at block 
2630. In one embodiment, the biller bank must convey the notification to the 
biller within two days after receiving it. The biller updates its database with the 
invoice delivered status at block 2640. 



25 One embodiment of the present invention is described in Appendix 1. As 

stated in Appendix 1, this embodiment includes a category of participants 
referred to as "statement originators." Statement originators include billers that 
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generate invoices, but also include other entities such as banks and stock brokers 
that provide periodic statements to customers that are not bills for services but 
that provide information to customers (such as bank account balances). Such 
non-biller statement originators may use the invoice delivery capabilties of the 
5 present invention to deliver electronic versions of their periodic customer 
statements in the same manner as billers use the invoice delivery capabilites of 
the present invention to deliver bills. 

The embodiment described in Appendix 1 also includes options for 
including interactive fields in statements delivered to customers. These 
interactive fields allow the customer to request additional information by 
activating an interactive field. For example, a statement may include an 
interactive field consisting of an advertisement for a product or service provided 
by a third party. Activating this field, for example by positioning a cursor on the 
15 field and activating a mouse button, causes the retrieval of information about the 
product or service. In one embodiment, activating an interactive field creates a 
link to a web page on the World Wide Web. 



Additional details of this embodiment are described in Appendix 1. 



The present invention can be implemented by means of software 
programming on any of a variety of one or more computer systems as are well 
known in the art, including, without limitation, computer systems such as that 
shown in Figure 27. The computer system of Figure 27 may, for example, be 
25 used as a customer computer, a biller computer, a bank computer, or a system 
manager computer. The computer system shown in Figure 27 includes a CPU 
unit 2700 that includes a central processor, main memory, peripheral interfaces, 
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input-output devices, power supply, and associated circuitry and devices; a 
display device 2710 which may be a cathode ray tube display, LCD display, gas- 
plasma display, or any other computer display; an input device 2730, which 
may include a keyboard, mouse, digitizer, or other input device. The computer 
system may or may not include non-volatile storage 2720, which may include 
magnetic, optical, or other mass storage devices, and a printer 2750. The 
computer system may also include a network interface 2740, which may consist . 
"° of a modem, allowing the computer system to communicate with other systems 

s over a communications network. Any of a variety of other configurations of 

CP 

5 10 computer systems may also be used. 

S3 

0 Thus a novel system for electronic invoice presentation has been 

|fl presented. Although the present invention has been described with respect to 

certain example embodiments, it will be apparent to those skilled in the art that 
15 the present invention is not limited to these specific embodiments. . For example, 
J§ although the operation of certain embodiments has been described in detail 

01 using certain detailed process steps, some of the steps may be omitted or other 
similar steps may be substituted without departing from the scope of the 
invention. Further, although the invention has been described as utilizing the 

20 VisaNet(TM) as a transport network, other networks or other communications 
media may be used. 
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Introduction 

This document presents the planned Bystem architecture for Visa International^ (Visa's) 
Electronic Statement Presentment System (ESP). ESP will represent a major extension 
of Visa's existing Electronic Payments System (ePay). 
A Phase I Pilot Program for ESP is scheduled to commence in early 1997. 
Figure 11 - Customer and Statement Originator ESP Architecture on page 3 shows the 
major players and the types of data transferred through Visa's ePay System, as extended by 
j» the ESP project. Principal players (or roles) include: 

55 • Statement Originators. Organizations that originate statements or bills, e.g., 

V a bank issuing statements or a local business issuing monthly bills to its 

a«j customers. 

5 • Billers. A subset of Statement Originators that originate Statements having an 

5? amount that is due and payable. 

P « Biller Financial Institution. Financial institutions that serve Billers by 

Sj receiving payments on their behalf sent through Visa's ePay system, and by 

m sponsoring Statement Originators into the ESP System, 

O • Statement Service Providers (SSPs). Organizations that receive statement 

JJ data from one or more Statement Originators and cause it to be delivered either 

Ul ' via Visa's ESP system or otherwise (e.g., U.S. Mail); These may be financial 

a institutions or other institutions sponsored by financial institutions. 

£ • Visa International. The world's largest processor of credit card transactions. 

u Visa develops, maintains and promotes the Visa ESP Service. This includes the 

Cf ESP System, operating rules, standards, and related pricing. 

% . Customer Financial Institution/Service Providers (CSFs). Organizations 

m that receive statement data from multiple Statement Originators via Visa's ESP 

System or otherwise and deliver these statements to Customers electronically. 

• Originating Banks. Financial institutions that hold the accounts Customers 
use to pay Statements. 

• Customers. Statement recipients. Examples of Customers include individuals 
like you and me, as well as businesses. 

Some organizations may carry out multiple roles. For example, a financial institution may 
be both Statement Originator and Customer Financial Institution. Very large Statement 
Originators may function as their own Statement Service Provider. A financial institution 
may choose to become both a Statement Originator and a Customer Financial 
Institution /Service Provider. 

Statement Originators must be sponsored into Visa's ESP Service by a Bilkr Financial 

Institution to participate. This usually entails a contract and payment of fees. 

Vi«a will access fees for the ESP Service only to Biller Financial Institutions and Customer 

Financial Institutions participating in the service. These organizations determine xee 

structures and rates to Statement Originators and Customers. 

For a description of the differences between the architecture described in 

Versions 1.1 and L2 of this document, see Appendix A - What's New ? on page 84. 
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ESP System Architecture 



Overview 

For a description of the differences between the architecture described in 
Versions 1.1 and 1.2 of this document, see Appendix A - What's New ?on page 84, 

A. The System 



1. Components 

C As shown in Figure 11 - Customer and Statement Originator ESP Architecture on page 3, 

3 the full ePay system consists of a Payments "layer", which is used to process electronic 

payments made by Customers to Statement Originators, and a Statement layer" which is 
-J used by Statement Originators to present electronic versions of Statements to Customers. 

Q The flows of data in the Payments layer of the system are shown in dashed lines and are 

J marked ^Outside of ESP Project's Scope". 

3 The Payment layer of ePay passes data for Payments from a Customer's PC to an 

O Originating Bank which submits the Payment to Visa's Base II computer system. Base II 

Hi settles the transaction and sends it to a BiUer Bank Workstation (BBWS) at the Baler's 

W Bank who updates the Baler's account. 

o 

p 2. Data Flow 

t° As shown in Figure 22 - A Simplified ESP System Data Flow on page 4, the ESP System 

U, passes Statement data in the other direction, in three distinct streams. The first two 

« streams consists exclusively of character data; the other stream contains both character 

□ data and binary data associated witk graphics (e.g., logos) and other multimedia features 

-j] sounds and movie clips). 

*0 The first stream of character data, consists of Statement Content Records,*™ sent in 

m batches of sets, where each set represents one Customer Statement for one billing cycle It 

is relatively small (1 to 5 KB, depending upon the Statement), but must be transmitted for 

every Statement processed. 

The second stream of character data, consists of Administrative Messages, are sent 
between all parties in the system. 

The third stream, the binary data, consists of Statement Templates, e ach represe nting the 
format and layout of a single Statement Type. It is relatively large (30k to 100k, depending 
upon the Statement), but is transmitted only when a change to the Statement format is 
made. 

The Statement Content Records {SLR,SAR, and SCR in Figure 1 - e.g.: amount due, 
transaction details, etc.) begin at the Statement Originator's A^departm^nt and are 
transmitted to the Statement Service Provider's (SSP) System. They are ^/*^ * 
Visa's Statement Originator Side ESP Workstation, where they are processed for transfer 
^!S^^8uMh 9 and on to Visa's ESP Statement Generation Workstatwn at the 
CSFs site. 

See Appendix Q ■ ESP System Data Flaw Projections. 
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3. Rendering the Statement 

As shown injure 33 - Generating the Fully-Rendered Statement on page 5, a set of 
Statement Content Records are combined with their Statement Template into Fully 
Rendered Statement PDF Files. These are then passed to the CSP^s Home Banking 
Software front end for delivery to Customers either via private network or the World Wide 
Web. 

B. Performance Objectives 

Key performance objectives for the ESP system include the: 

• Capability to produce consistent presentation-quality Statements completely 
within the control of the Statement Originator. 

• Capability to produce Statements of arbitrary complexity, including variable 
length, multi-section Statements whose content and format could depend on 
Customer-specific data. 

• Capability to display and print Statements r taking maximal advantage of 
available hardware, independent of platform and operating system. 

Capability to display interactive Statements with features, including for 
example, pay buttons, optional targeted marketing Generic Enclosures, World 
Wide Web links, the ability to transmit blank forms and receive forms data (e.g., 
loan applications), as well as the ability to play sound and video clips. 

W\ • Economic data transmission. This is accomplished by dividing Statements into 
5 durable template data and volatile content data, storing the durable data as near 

M= to the Customer as feasible, and thereby minimizing transmission of repetitive 

□ data through the system. 

o 

^0 
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v 
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Statement Content Record Sets 
are received from the ePay 
Switch, and loaded into a 
secure (SQL Server) database. 

Statement Content Record Sets 
are processed into Fully 
Rendered Statement PDF Files 
as follows: 

• A Statement Print Image is 
produced in PDF format by a 
Microsoft Access Report. 

• The Access Report also 
generates a PDF Merge 

- Control Table, specifying 
which PDF Files are to be 
merged to make up this 
Customer's Statement. 

• PDF Files are merged, 
under control of the PDF 
Merge Control Table y to 
make up the Fully Rendered 
Statement PDF File. 

PDF Files can be Statement 
Originator-Specific Interactive 
. Pages or Generic Enclosures. 



Figure 3 - Generating the Fully-Rendered Statement PDF File 
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C. A Glossary 



1. The Players 



Statement Originator 


Organizations that originate statements or bills, e.g., a bank 
issuing statements or a local business issuing monthly bills to 
its customers. 


Biller 


A subset of Statement Originators, organizations that 
originate Statements that have an amount due and payable. 


Biller Financial Institution 


Financial institutions that serve Billers by receiving 
payments on their behalf sent through Visa's ePay system. 


Statement Service Provider 


Organizations that receive statement data from one or more 
Statement Originators and cause it to be delivered either via 
Visa's ESP system or otherwise (e.g., U.S. Mail). These may 
be financial institutions or other institutions, including 
Statement Originators* sponsored by financial institutions. 


SSP 


A Statement Service Provider 


Visa International 


The world's largest processor of credit card transactions. 
Visa develops, maintains and promotes the Visa ESP Service. 
This includes the ESP System, operating rules, standards, 
and related pricing. 


Customer Financial 
Institution/Service Provider 


An organization that receives statement data from multiple 
Statement Originators via Visa's ESP System or otherwise 
and delivers these statements to Customers electronically. 


CSP 


A Customer Financial Institution /Service Provider, 


Originating Banks 


Financial institutions that hold the accounts Customers use 
to pay Statements. May or may not be a CSP. 


r 


Statement recipients* Examples of Customers include 
individuals like you and me, as well as businesses. 

Identified by one or more unique combinations of UBF BiUer 
ID and CBAN. II 




I UBF Biller W 


A unique Visa-assigned number identifying the Statement 
Originator. 12 digits 


SSP Biller ID 


How the SSP knows the Statement Originator. 


SSP ID 


A unique Visa-assigned number identifying the SSP. 
"B* & 5 digits. 


CSPW 


A unique Visa-assigned number identifying the CSP. 
"C* & 5 digits. 


CBAN 


Customer Riller Account dumber. How the Statement 
Originator knows the Customer. 


CSP Account Number 


How the CSP knows the Customer. Not required. 
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2. The Statement 


Statement 


A collection of Documents from a single Statement Originator, 
addressed to a single Customer, for a single Statement Cycle 
Date. Traditionally mailed in a single envelope. 

May or may not include an Amount Due. 

In an electronic statement, one document is mandatory, 
consisting of both Customer-Specific- and Static Documents. 
Other documents are optional and made available at the 
Customer's request. At most, one optional document is 
Customer-Specific: the others are Static. 


Document 


A portion of a Statement which may be Static, Data-Bound- 
Fixed-Length or Data-Bound-Variable-Length. An entire 
Document may be included or not included for a given 
Statement. Each Document usually consists of one or more 
_pages I „ . ■ 


Static Document 


A document whose contents is the same for all Customers 
receiving a given Statement during a given Statement Cycle 
Date. - 


Customer-Specific Document 


A document whose content is different for each Customer 

. • _ „ -, r ^_ cztntomo-nt during & triven Statement Cycle 
receiving a given otatement uunug «* giv**** ^ - f 

Date ■ 


Generic Enclosures 


a G+ntfa Document - one that is the: same for ALL copies of 
the Statement, regardless of tho Customer's data. 
Traditionally included within a Statements envelope. 
Represented as a FD* tile. „ — 


Interactive Page 

1 


Adobe Acrobat Forms Objects in a PDF file which can be 
oHHaH tn a Statement PDF file during creation of the Fully 
Rendered Statement PDF File. 
For an example, see Figure 44 - A Mock-Up of a 
Statement on page 11. . . ■ — 


Mandatory Customer-Specific 
Pages 


The main Customer-Specific Document, included on all 
Statements E.e.: a bill summary. . 


Mandatory Generic Enclosure 


A Generic Enclosure included on all Statements. E.g.: 


Optional Customer-Specific 
11 Pages 


A Customer-Specific Document which may be requested by 
the Customer via the Interactive Pose. F ff.: hill details. 


Optional Generic Enclosure 


One of possibly several Generic Enclosures which may 
be requested by the Customer via the Interactive Page. 
E.g.: promotions. . 


Fully Rendered Statement PDF 

Pile 


A Statement ready for viewing by the Customer, in a single 
Adobe PDF (portable Iincument Eormat) File. 


Optional Customer-Specific 
PDF File 


A PDF File containing Optional Customer-Specific Pages. 
At most, one per Statement. . 


Optional Generic PDF File 


A PDF File containing Optional Generic Enclosures. There 
1 may be several of these for one Statement 
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Mini Statement 


A summary of a Statement, typically based on 
Statement Descriptor data, and typically used for 
displaying a Statement on a non-conforming device 
(e.g.: a touch-tone telephone, as opposed to a PC or 
Macintosh). . 


Statement Cycle Date 


A Statement reflects business done during a given time 
period, often one month. H ==^= 



Statement Descriptor 


A fixed set of data fields, common to ALL Statements. 

The data necessary for the CSP to generate a Mini Statement 
for the Customer and to allow the Customer to pay the 
Statement through the ePay system. This includes all 
necessary control and routing data. 

<r , « • ii r* * . A Cl /"ITT AA«nma_i4allTf1lfAn T*Otf*ftT*fl ft T"lfl 

It is in the form of an ASCII comma-aeumiiea recuru, tuw 
includes the filename of the associated Fully Rendered 
Statement PDF File. 

This data is defined on page 42 and depends upon Statement 
Type. .. 


Statement Types 


Currently, three distinct Statement Types have been defined: 
Invoices, Account Summaries, and Advisory Messages 


Invoices 


The defining characteristic of an Invoice is that it can (but 
need not) contain a demand to be paid a specified amount by 
a specified date. . 


Account Summaries 


The defining characteristic of an Account Summary is that it 
reports a summary of activity pertaining to a financial 
account, and does not contain an explicit demand for 
payment. = 


Advisory Messages 


An advisory message is essentially a free text message 
delivered electronically. ' 
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Statement Template 


A Microsoft Access *.MDB file containing the resources 
necessary to generate a Statement from a Statement Content 
Record Set Contains Statement Stationary and, optionally, 
other binary resources. Relatively large. 


Statement Template Number 


A unique Visa-assigned number identifying the Statement 
Template. T & 7 digits. E.g.: T0040456 


Statement Template Version 
Number 


A 'Visa-assigned number identifying a version of the 
Statement Template. 4 digits. E.g.: 1056 


Statement Template W 


Statement Template Number + V+ Statement Template 

IT XT t Tl mnAilA)tCC.>1ACC 

Version Number. E.g.: T0040456vl056 


Template Resource 


Every resource file used by a Template. Pont files j PDF files, 
graphics, etc. 


Template Resource ID 


Statement Template Number + *_"+ Statement Enclosure 
Number. Assigned sequentially by Visa. E.g.: T0040456_J)031 


Statement Stationary 


The stable portion of a Statement^ in a format analogous to 
printed stationary. Relatively large. 


Statement Content 
Transparency 


HTUn -tmlafila nAi4l*An O QtntoTn£>Tlt in PT1P fnTTTint". RfllfltlVfilV 

xne volatile portion oi B onwc"Kzn* m ^us luimtiit. iwiowtd»j 
small. - 


Retention Period 


The period of time that Statement Content Data is kept at 
the ESP Statement Generation Workstation. Typically 6 
months. 


Statement Generation 


Creation of one or more Statement PDF file(s) from a 
Statement Content Record Set. 


Statement Rendering 


Processing of one or more Statement PDF files and, 
optionally. Statement FDF files for display. 


Standard Statement Rendering 
Tool (SSRT) 


Software designed to generate and display a Statement. 
See The Standard Statement Rendering Tool on page 49. 
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SAR Stream 


Statement Legacy Records, Augmented - "Print Stream" 
Statement records sent from the Statement Originator to the 
£>or% tor Customers wno nave requesiea &or amivmjr ui uus 
Statement, with data added by the SSP to assist with £SP 
processing. 


SAR Record 


A' uiutml Awm 4- Via Oil J? Q+vorr m . II 


SAR Statement Record Set 


The SAR Stream records pertaining to a single Statement 


SAR Document Record Set 


The SAR Stream records making a single Document 


SAR Stream Type 


These records come in a wide variety of formats: Fixed- 
Length, Delimited, una Print Stream records are three of the 
formats found in use today. SAR data may also be stored by 
the SSP in an SQL database* 


Statement Content Data 


Parsed and fielded SAR data used to generate a Statement. 


Statement Content Record Set 


Statement Content Data for a single Statement. May be in 
comma-delimited ASCII format for transmission, or in a 
Statement Content Table Set. 


Statement Content Table Set 


a Dn f got foKloa atArad in" an ODBC-compliant database at 
the CSP. Contains Statement Content Data for: 

• one Statement Template 

• many Customers 

• many statement rertoas vaaia prior to me iic^wuit 
Period is purged)) _! 


Transmission Number (Xmn #> 


This sequential number is assigned to each e-mail 
transmission. It is unique within each transmitter. When 
concatenated behind the transmitter's identification 
("ePaySw", SSP ID, or CSP ID), it forms a system-wide 
unique identifier. 

e.g.: "ePavSw.342045", "B 12345. 23432" 


Hash Total 

■ 


A value calculated from a pre-defined set of data within an e- 
mail message, ASCII file, SQL table, or other data collection. 
This value is tvpicallv used to detect changes to the data. 
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The Details 

A. The Statement 

A Statement is presented to a Customer as a Fully Rendered PDF File. ^ Customer views 
this PDF File via Adobe Reader, either as a Web Browser add-in or as an OLE Object in a 
proprietary home banking system. 

1. A Sample Statement 




FURNITURE RENTAL IMC. 

HOME 4 OFFICE M „_,« 

P. a BOX 100515 PASADENA, CA 91 1 89-0815 



01012222223000000004 *»°0O0O*^°gC^W 



ST 

SUB IB Q EOBL J C 




J3IX6 » 90 VLAOt 



Figure 4 - A Mock-Up of a Statement 

In Figure 44 - A Mock-Up of. a Statement on page 11, the CSP is "Very 
Friendly Bank" and the SSP is "Brook Fu rniture Rentals 




In this example: 




The PDF Ffle consists of three parts: the CSFs Home Banking Software, the 
Interactive Page, and the Statement. 
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a. CSP's Home Banking Software 



In our example, the Home Banking Software iB web-based on a 
private Intranet (you can see Microsoft's Internet Explorer in the 
background). The CSP-supplied "Pay It" button is, in this case, an 
HTML button. 

Many Home Banking Software systems are based on proprietary 
software that in normally run without connection to the CSP* s 
system. It dials up the CSP only when the Customer requests 
uploads or downloads of data. We refer to this type of system as 
"proprietary, off-line". 



Either type of system can use Adobe's Reader software to display the 
Fully Rendered Statement PDF Files generated by the ESP System. 
(Note that Figure 4 uses Adobe Exchange - in production, Reader 
will be used instead). 



The Interactive Page 



on tfic birth Vj\ mmfm 
of your new J-J 
dwJgWcr Kitten, M» Public I 




This consists of an Adobe PDF Form that has 6 Objects: the "New 
Warehouse", "Lower Rates", "Office Furniture", and "Edwardian" 
buttons, which are "generic" - common to all Customer's Statements; 
a non-interactive graphical area showing the "Rirsten" message, and 
the "Baby Furniture" button. 

The "Kirsten" message and "Baby Furniture" buttons are generated 
specifically for Ms Public's Statement by the Access Report, and are 
added to the form via an Adobe FDF file. 



i. The Buttons 

Each of the Adobe buttons can have one of a pre-defined set. 
of actions. At this time, the following actions are defined: 

c Download Optional Enclosure x 

e Download Optional Customer-Specific Pages 

During generation of the Customer's Statement, the 
Template generates the FDF File which defines, among other 
things, the actual actions taken when each of the buttons are 
pressed. 
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For example, pressing a "Show Optional Enclosure 4 button 
on a web-based system may cause a web link, to a CSP- 
specific URL, while pressing the same button on a 
proprietary off-line system may cause execution of a program 
which places an order for "Optional Enclosure AT on the 
download queue for the next connection to the CSP. 

The exact definition of these actions have yet to be 
determined. 

c. The Statement 

A Statement consists of four parts: Statement Descriptor, Fully 
Rendered Statement PDF File, Optional Customer-Specific Pages, and 
Optional Generic Enclosures. 

i. The Statement Descriptor 

This ASCII text contains all data necessary to pay the 
_ Statement and to. display it on Non-Conforming Devices. 

O See page 42 for a definition of the Statement Descriptor. 

CO h. The Fully Rendered Statement PDF File 

The Interactive Page, Mandatory Customer-Specific .Pages & 
Mandatory Generic Enclosures are all included in the Fully 
7 " Rendered Statement PDF File. 

M- The Mandatory Customer-Specific Pages are generated by 

O the Access Report within the Statement Template for each 

O Customer's Statement. 

J3 The interactive Page and the Mandatory Generic Enclosures 

£ are separate PDF Files. 

y E These and, optionally, a Customer-Specific ™F File, are 

merged with the Mandatory Customer-Specific PDF File to 
make the Fully Rendered Statement PDF File. 

HI . optional Customer-Specific Pages 

' A second, Optional Customer-Specific PDF File, is generated, 

at the discretion of thfe Statement Originator, by a second 
Access Report within the Statement Template. 

/v. Optional Generic Enclosures 

Any number of Optional Generic Enclosures can be defined 
^ Statement. These are in the form of PDF files, which 
are downloaded at the Customer's request. 

2. Performance Considerations 

Bv keeping the Mandatory Customer-Specific Pages end Mandatory Generic 
lnltlur7s ^ smaU a* possible, and by placing as much detail as possible 
fiXffS^^ ^ Statement Originator can 
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greatly decrease the time it takes the Customer to see and pay their 
Statement. 

Statistics on downloads of Optional Customer-Specific Pages and Optional 
Generic Enclosures will be kept and made available to the Statement 
Originator. 



m 

"0 
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B. TPL - The Statement Template 

A Statement Template is a Microsoft Access v7.0 Database (an MDB file). Associated binary 
resources are stored within the MDB file. This file can be compressed by PKZip for efficient 
transmission and storage at the ePay Switch, 

In addition, Static Documents (Mandatory and Optional Enclosures) are passed as Adobe 
PDF Files, which are transported and catalogued separately. 

The power of Access Reports places few limits on the printedscope of the Statements that a 
Statement Originator can define. Non-print objects, such as sounds, video, web links, etc., 
are included as binary objects within a PDF file.. 
C See Figure 55 - The Statement Template on page 16 for a definition of a Statement Template.. 

to 

"° 1 . Statement Template ID 

6 A Statement Template is identified by a Statement Template Number, T + a 

m Visa assigned 7 digit number (e.g.: T0000001), and a Template Version 

O Number, a Visa assigned 4 digit number (e.g.: 1^3)^0^, separated by 

O a V, they form a Statement Template ID, (e.g.: T0000001vl033). 

2 Statement Templates are referenced by the Template Data 

O Template Index Table (see page 41). 

ys 2. Template Resource ID 

f. Every resource file used by a Template is assigned a Template Resource ID. 

0 Statement Template Number + "_'+ Template Resource Number. Assigned 

O sequentially. E.g.: T0040466_0031. 

* ' Template Resources are independent of Template Version Number. That is, 

* any version of the Template can reference any Template Resource. 
m Examples of Temp/aiei^ 0 «n»s: TO040456_0031.wav (sou^ file), 

T0040456_0032.pdf (PDF File), T0040456_0033.fon (font file), etc. 

3. The Standard Template 

A Standard Tewplate C.mdb ^^^^^^J^^a^ 
Template Generation Workstation to assist m S^^nfTempkUes Ttus 
Template will have a simple Statement Content Table Definition describing 
SeUs Sined I the Statement Index File (see page 42), and w.11 produce 

a one-page Mini Statement, 
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4. Incremental Template Updating 

Statement Originators are expected to make some change to their Templates 
with each billing cycle (e.g., monthly). Since each Template is an integral 
*.mdb file, typically ranging between 0i5 and 1.5 mB in size, a full update of 
these Templates across the system would be prohibitively costly, particularly 
when the full update must be broadcast to tens of CSPs. 

Hence, one requirement for ESP design is that Template updating be 
efficient in terms of data communication. That is, we want to ensure that 
^ only changed data is transported with each update, and that unchanged data 

C is not transported unnecessarily, A second requirement is that pre-pilot 

10 coding effort be minimized to reduce schedule risk. 

For commercial scale operations, the update procedure will be as follows: 

O • The initial version of a Template (e.g., T1234567v0000) will 

'U\ contain all necessary elements within one *.mdb file. 

^ • Any changes whatsoever to this Template will cause the ePay 

s Switch to issue a new version number (e.g., T1234567v0001). 

FU , 

m * Changes will be passed as *.mdb files also; however, only those 

£3 elements in the Template that have been changed will need to be 

™ included. Since these *.mdb files will contain only changes to 

code modules, they can be compressed to very small size. 



HI 



These changes might include new resources (PDF files, fonts, 
etc.), new report definitions, or new code modules. 



• The update .mdb file will be designated appropriately (e.g. 
4? U1234567v0001). 

yj A general procedure will be written to combine the existing full version with 

01 the new update to produce a new full version (T1234567v0001); This general 

procedure will be made available to the ESP Template Authoring 
Workstation so that the merger process can be verified by the Statement 
Originator. The procedure will also exist at the ePay Switch and at the ESP 
Statement Generation Workstation. 



a. How It Works 

When the ePay Switch receives an update Template, it first attempts 
to merge the update with the existing full Template and validate the 
result. If this is successful, then the ePay Switch saves both the new 
full Temptae and the update as two distinct .mdb files, and sends an 
Ack response to the ESP Statement Origination Workstation. If this 
is unsuccessful, then the ePay Switch sends a Nak response to the 
update request. 

Statement Content Records passing through the Statement 
Origination Workstation are stamped with the version number of the 
Template processing it. When Statement data with the ne w 
Template version is received at an ESP Statement Generation 
Workstation, a new Template must be pulled from the ePay Switch. 
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If the Statement Generation Workstation has the most recent prior 
Template stored locally (e.g.: T7654321v0056, when it needs 
T7654321v0057), it can request just the update .mdb file. Otherwise, 
it must request the fall .mdb file; Two different ADV messages are 
provided to indicate the nature of the request. 

b. For the ESP Pilot 

Notwithstanding the preceding, this incremental Template updating 
capability may be stubbed out for pilot to minimize schedule risk and 
since data flows will be low. 

That is* Statement Generation Workstations will ALWAYS request 
full updates, and the ePqy Switch will respond to BOTH update and 
full requests with full Templates. 

That way, as Pilot systems are converted to production capability, no 
errors will occur. 

C. ESP System's Data Transmissions 

The ESP System moves Statement Content Records and Admin Messages from the ESP 
Statement Origination Workstation to the ePay Switch and from the ePay Switch to the ESP 
Statement Generation Workstation. 

It also moves Admin Messages in the other direction. This traffic is in one of three forms: 
Statement Content Records, Simple Admin Messages, and Complex Admin Messages. 



a 
m 
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The following examples show Microsoft's Exchange Client, a user interface to Exchange. 
ESP will do much the same things, but under program control. 

1 . Statement Content Records 

Statement Content Records travel in Sets. A Statement Content Record Set is 
all of the records needed to generate a single Statement. Several of these 
Sets (up to some specified limit, say 5,000 - depending upon e-mail efficiency) 
are transmitted to a single CSP at once. 

See The ESP Statement Origination Workstation on page 53 for a complete 
description of Statement Content Record transmission. 

Note: this e-mail example contains two enclosures: ASCII Files 
T1234567vl006.txt & T1234567vl006Jtems.txt. 




Figure 6 - A Statement Content Record E-Mail 

Simple Administrative Messages 

These e-mail messages are generated one line at a time - each line is one 
message. 

They are transmitted when they reach some limit of records, when an urgent 
event occurs, or when a Request Ehd-of>Day Shutdown Admin Message is 
received. 

Note the "Type" column. "SCR* is "Statement Content Records" \ "Tlx" is 
Transmission Index", and U ADV is "Administrative Messages, Visa 
Format". Other possibilities include *TAk" - Transmission 
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Acknowledgment" t and all of the simple of the ADVs defined in the UBF - 
Universal Biller File on page 28. It is not necessary that this column be 
restricted to 3 characters. 




ESP Tiflntrnri Bion Control 

|38nder_ArchlvB 



To 

C01234323 147904833 1998-07-06 14:33 SCR 
ESP Archive 147904834 1998-07-06 14:33 Tlx 
C00234123 14790483S 1998-07^06 14:34 ADV 
C00987132 147904836 1990-07-06 14:34 SCR 
ESP Archive 147904837 1998-07-06 14:34 Tlx 



Xran U 



Date £ Time 



Type Hash 

798432980 
393930954 
003240243 
793128328 
828131932 



Reccd Encl Bytes 



100 
100 
100 
100 
100 



1667 
0 
O 

1851 
0 



s 



Figure 7 - Simple Administrative Messages E-Mail 
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3. Complex Administrative Messages 



These E-Mails are one message each. Their data can be ASCII text, as in the 
figure below, or binary enclosures, such as Statement Templates or Template 
Resource Files, 




Figure 8 - Complex Administrative Message E-Mail 



4. Properties of All Electronic Mall Transmissions 

As can be seen in the previous examples, all transmissions have the 
following properties: main destination CW), copy destination ("CCD, 
Transmission Number (Xmn #)* Title, and Hash Total 

a. Main Destination ("To") 

For Statement Content Records, this will be the Customer's CSPID. 
For Admin Messages (ADV), this will be a CSP ID, a SSP ID, ESP 
Transmission Control, ESP Archive, or ESP Template Control, 

b. Copy Destination ("CC") 

For Statement Content Records, this will be ESP Archive, 

c. Transmission Number (Xmn #) 

This is a sequential number unique within each transmitter. 
Concatenated behind the transmitter's identification ("ePaySw", SSP 
ID, or CSP ID), this forms a system- wide unique identifier. 

If forms the first part of the message's Subject line. 

E.g.: 'Xmn # 147904834 - Template Update - Hash 32178992" 
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d. Title 

What this transmission contains. 

It forms the second part of the Subject line. 

E.g.: "Xmn # 147904834 - Template Update - Hash 32178992" 

e. Hash Total 

Each type of message will have a rule for generating a hash total. 
For Statement Content Record transmissions, it will be the addition 
of the ASCII values of one or more of the Statement Index fields (see 
^ page 42). 

0) It forms the third part of the Subject line. 

=0 E.g.: "Xmn # 147904834 - Template Update - Hash 32178992" 



m 



5. Duplicate File Control 

The following section applies to all parts of the ESP System sending 
e-mail messages. 

HJ To ensure that e-mail messages are not sent more than once by mistake, the 

£S Transmission Log (see page 46) is kept. This is a record of each 

O transmission and its hash total. 

S£ Before a message is queued for sending, its hash total is compared to all of 

y 1 those on the table. If a match is founds the message is sent to a suspense 

s mailbox and an operator message is generated. 

q To be transmitted, the message must be manually requeued by the operator. 

3 6. ESP Transmission Control 

The following section applies to all parts of the ESP System sending 
e-mail messages. 

ATT, e-mail messages sent MUST be accompanied by a Transmission Sent to 
ePay Switch ADV sent to the ESP Transmission Control mailbox. This ADV 
includes a hash total calculated from prerdetermined values within the 
message. 

In addition, ALL e-mail messages received MUST be accompanied by a 
Transmission Received from ePay Switch ADV to the ESP Transmission Control 
mailbox. This ADV also includes a hash total calculated from the same pre- 
determined values within the message. 

During normal operation, when an e-mail message is generated, it is copied 
into the generation workstation's "Sender Archive" mailbox. 
When the ESP Transmission Control mailbox receives a Transmission 
Received ADV corresponding to a valid Transmission Sent ADV, with the same 
hash totals, it forwards the ADV to the workstation that originally generated 
the message. Upon receipt of the Transmission Received ADV, the workstation 
deletes the original message from its "Sender Archive" mailbox. 
If delivery of the message fails for some reason, a "Message Not Delivered" 
message is sent to the workstation. Receipt of this message results in 
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notification of the operator and automatic retransmission (up to a pre- 
determined number of times). 

In this way, delivery is assured. 

7. ESP Archive 

A requirement of Visa switching systems is that all traffic through them 
must be available for auditing purposes for some pre-defined period of time. 
This is accomplished at the ePay Switch via the ESP Archive mailbox. 

Rather than slowing down processing of message traffic with mail robots 
(Visual Basic programs manipulating e-mail messages via MAPI - Messaging 
C Application Erogramming Interface) reading every message, significant 

Jfl messages are forwarded to the ESP Archive mailbox, where they are stored 

"5 for later research. 

H All Statement Content Record Messages are stored in their entirety. For 

O eac h suc h message, a separate Transmission Index Message is also sent to 

2 the ESP Archive mailbox. This message is an index showing the CBANs 

w represented within each Statement Content Record Message. 

S The Standard Statement Rendering Tool (see page 49) can then be used to 

2 " recreate ANY Statement that passes through the ESP System. 



m 



43 



8. End-of-Day Processing 

To ensure that all e-mail transmissions are accounted for, the entire ESP 
System will be closed for a period each day, during which traffic reporting 
will be performed. 

a. The ePay Switch Initiates End-of-Day Processing 

The ePay Switch initiates End-ofrDay Processing by sending a 
Request End-of-Day Shutdown ADV to each ESP Statement 
Origination Workstation and to each ESP Statement Generation 
Workstation in the system which has not already sent in an Encf-o/*- 
Day Shutdown ADV. 



b. The Workstations Respond 

The Workstations can perform End+of-Day Processing in one of two 

by waiting for the Request Endrf-Day Shutdown ADV 
from the ePay Switch before stopping processing and 
sending their End-of-Day Shutdown ADV, or 

by sending an End-of-Day Shutdown ADV when they 
have finished their days processing, and then shutting 
down. 

The ePay Switch Reports 

Once End^of-Day Shutdown ADVs have been received from all 
workstations, the ePay Switch will stop processing newly received 
messages and will generate its End-of-Day Reports, These reports 



ways: 



« 
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will include a traffic analysis for each workstation (messages 
received + messages stored = messages sent + messages on hand) and 
other reports. 

Each workstation will then be sent its End-of-Day Report. 

d. The ESP System Restarts 

Those workstations left running will sign on to the ePay Switch and 
look for their End-of-Day Report messages. If they do not find it, 
they will try again later. 

Workstations which sent their End-of-Day Shutdown ADV's before 
~» receiving the ePay Switch's Request End-of-Day Shutdown ADV, and 

l£ which were shut down, will look for their End-of-Day Report message, 

i upon starting up. 

H Once the End-of-Day Report message is received, operations will 

Q proceed. 

? Comparison of the End-of-Day Report from the ePay Switch and the 

° workstation's own End-of-Day Report is a manual operation 

performed by the workstation's operators. Any discrepancies must 
be dealt with manually. 



Potential Problems and Their Effects 



iff The ESP System has three kinds of data transmissions: 

Administrative Messages (ADV), Templates, and Statement Content 
y, Records. 

O The following potential problems have been identified: transmission 

O not received, transmission received more than once, transmission 

~Q garbled. 

£ Each of these errors are detected and corrected my Microsoft 

Exchange. In addition, the ESP System will cheek itself, as follows: 
All transmissions are copied to a local holding area AND they 
and their hash totals are recorded at the Transmission 
Control mailbox at the ePay Switch. 

Upon receipt, the hash totals are checked and the 
Transmission Control mailbox is notified. It, in turn, notifies 
the sending workstation, which deletes its copy of the 
message from its local holding area. 

L Transmission Not Received 

(a) Detection 
During End-ofDay Processing, transmissions are left 
in the local holding area OR the Transmission 
Control mailbox is cut of balance, 

(b) Correction 

Locate the lost message. Re-transmit if necessary. 
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ii. Transmission Sent More Than Once 

(a) Detection 

Each transmitting workstation keeps a Transmission 
Log (see page 46), recording each transmission made 
with its hash totals. Detection of a duplicate hash 
total will cause the transmission to go to a suspense 
mailbox where the workstation operator will have to 
manually release it 

(b) Correction 

(i) Administrative Messages (ADV) 

Each AD V message will have to be examined 
and a strategy developed to handle duplicates. 

(ii) Templates 

Duplicating a Template transmission will 
have no effect 

(iii) Statement Content Records (SCR) 

Duplicate SCR transmissions will be rejected 
by the ESP Statement: Generation 
Workstation via referential integrity errors. 

ill. Transmission Garbled 

(a) Detection 

A pre-defined hash total is calculated for each 
message before it is transmitted, and it is appended 
to the message's Subject line. 

Upon receipt, the same hash total is re-calculated. It 
the two totals do not match, an error has been 
detected. 

(b) Correction 

i. Notify the workstation operator. 

ii. Request a re-transmission. 
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D. ESP's Data 



Statement Originator Data 



a. UBF - Universal Biller File 

This is the definitive list of Statement Originators and Statement 
Originator relationships. It is extracted by the ePay Switch which 
uses it to generate the ESP Template /Originator Table for the ESP 
Statement Generation Workstation and the ESP Statement 
Origination Workstation; and the Statement Originator Xref Table 



m 
v 

Q 

m 
s 
o 
ru 
m 
o 
3 
in 



03 







Type 




Key 


UBF Biller ID 


Text 12. 


Unique Vis a- as signed number 




Expiration Date 


Date 






Effective Date 


Date 






SSPID 


Text 16 


"B" & Unique Visa-assigned number 




Statement Originator Name 


Text 






Statement Delivery Notification 
Flag 


Yes/No 


Does Statement Originator want to know 
when Customer downloads Statement ? 
SeeADV#8-8d 




Paper Statement Option 


Text 1 


T: Always Mailed 
"2": Never Mailed 

"3": Mailed at Customer request only 
"4": Not Mailed at Customer reauest only 




Who Authorizes Customers ? 

(Statement Originator Capabilities 
Parameter: byte 1 of 24) 


Textl 


"A": All Customers can sign up 

"B": SSP will confirm Customer sign up 

"E a : ESP will confirm Customer sign up 

SeeADV#l 




Full Statement Device Option 


Text 2 


"CD": Conforming Devices only 
"ND": Non-Conforming Devices only 
"CN": Both Conformine & Non-C devices 
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b. SSP Template/Originator Table 



m 

H 

o 

m 

o 

m 



O 

o 



Generated by the ePay Switch from the UBF and the Template 
Index File for the ESP Statement Origination Workstation, this table 
contains Statement Originators who are ESP Active. 

The Template OK field must be "Yes w and the UBF Expiration Date 
must not be passed before Customers can request ESP delivery of a 
Statement or Statement Content Record Sets for this Statement 
Originator can be passed from the ESP Statement Origination 
Workstation to the ESP system. 

The Template OK field is set when the Statement Originator 
successfully registers a Template with the ePay Switch. It is cleared 
if the last valid Template expires. 

Since Statement Content Record Sets can only be held for a short 
period of time at the ESP Statement Origination Workstation, 



3 






Qmiwto - : 


Key 


Template ID 


Text 8 


A Unique Visa-assigned number 
identifying a Statement Template. T & 7 
digits. E.g.: T1234567. 


Alt Key 


UBFBiUerW 


Text 12 


Unique Visa-assigned number 


Alt Key 


SSPBillerlD 


Text 16 


.. Number that the SSP knows the 
Statement Originator by 




SSP ID 


Text 12 






UBF Expiration Date 


Date 






UBF Effective Date 


Date 






Template Name 


Text 






Statement Originator Name 


Text 






Statement Delivery Notification 
Flag 


Yes/No 


Does Statement Originator want to know 
when Customer downloads Statement ? See 
ADY#8-8d 




Paper Statement Option 


Textl 


"1": Always Mailed, 
M 2": Never Mailed, 

"3": Mailed at Customer request only 
"4": Not Mailed at Customer request only 




Customer Sign Up 

- Statement Originator 
Capabilities Parameter: 
byte 1 of 24. 


Text 1 


. "A": All Customers can sign up 
TP: SSP will confirm Customer sign up 
SeeADV#l. 




Template OK 


Yes/No 


Is this a valid Template ? 
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CSP Template/Originator Table 



Generated by the ePay Switch from the UBF and the Template 
Index File for the ESP Statement Generation Workstation, this table 
contains Statement Originators who are ESP Active and their 



i 




Type \ 


ConurientB - 


Key 


Template ID 


Text 8 


A Unique Visa-assigned number 
identifying a Statement Template. T" & 7 
digits. E.g.: T1234567. . 


Alt Key 


UBFBiUerW 


Text 12 


Unique Visa-assigned number 




SSP ID 


Text 12 






UBF Expiration Date 


Date 






UBF Effective Date 


Date 






Template Name 


Text 






Statement Delivery Notification 
Flag 


Yes/No 


Does Statement Originator want to know 
when Customer downloads Statement ? 
SeeADV#8-8d 




Full Statement Device Option 


Text 2 


"CD": Conforming Devices only 
*ND": Non-Conforming Devices only 
"CN": Both Conforming & Non-C devices 




Template OK 


Yes/No 


Is this a valid Template ? 



en 



m 



□ 

o 

-a 
® 



2. Administrative Messages 



ADV - Administrative Messages, Visa Format 

They will be comma-delimited ASCII records in the following basic 



^ailS . . i 




From 


OTP BWerlD. or CSP ZD 


To 


UBP Biller ID. or CSP ID 


Create Date Time 


Date & Time to nearest second 


ADV Type 


Which message ? 


ADV Data 


Comma-delimited message fields, dependent upon ADV 
Type 
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ADC - Administrative Messages, Customer Format 

These are Administrative Messages in the format required for 
communication between the CSP*s Home Banking System and the 
Customer's PC. They are neither generated nor received by ESP 
components and are outside the scope of the ESP Project 



Customer Data 



G 

m 
o 
o 

fy 

n 
o 

m 
H 

o 
□ 

m 



a. SSP Customer Profile Table 

This Table is maintained at the ESP Statement Origination 
Workstation. It is passed on to the SSP where it is used to extract 
SAR Statement Record Sets for £SP delivery from the main Print & . 
Mail data stream. 

All changes must be authorized by the SSP or Statement Originator, 

Note that the CSP Account Number, the number that the CSP knows 
the Customer by, may be considered confidential by some CSFs (for 
example, it may be a bank account number). As a result, the 
combination UBF Biller ID & CBAN is used to uniquely identify a 
Customer. 










Comments * , ' 


Key 


UBF Biller IB 


Text 12 


Unique Visa-assigned number 


Key 


CBAN 


Text 12 


How' the Statement Originator knows the 
Customer 


Key Dec 


Expiration Date 


Date 






Effective Date 


Date 






Template Number 


Text 8 


Note: No Template Version Number 




cspm 


Text 7 


. "C* & Unique Visa-assigned number. 




Test Account Flag. 


Yes/No 


Used for SSP Test runs 




Advertisments Requested 


Text5 


Value assigned by SSP via ADV 




Hardcopy 


Yes/No 






Hard Copy Until 


Date 
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b. CSP Customer Profile Table 

This Table is maintained at the ESP Statement Generation 
Workstation. 

All changes will be triggered by receipt of a "Customer Statement 
Delivery Ack" or "Customer Statement Delivery Ack" ADV at the 
Workstation. 

Note that the CSP Account Number, the number that the CSP knows 
the Customer by, may be considered confidential by some CSP*s (for 
example, it may be a bank account number). As a result, the 
combination UBFBiller ID & CBAN is used to uniquely identify a 
Customer. . 



• 




• 

Type 




Key 


UBFBiller ID 


Text 1% 


Unique Visa-assigned number 


Key 


CBAN 


Text 12 


How the Statement Originator knows the 
Customer 


Key Dec 


Expiration Date 


Date 






Template Number 


TextS 


Note: No Template Version Number 


Alt Key 


CSP Account Number 


Text 20 


- Specified by CSP. Not currently used by ESP. 




Test Account Flag 


Yes/No 


Used for SSP Test runs 




Advertisments Requested 


Text5 


Value assigned by SSP via ADV 




Display Full Graphics 


Yes/No 






Summary Statements 


Yes/No 






Detailed Statements 


Yes/No 





o 
o 
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Template Data 



a. Template Index Table 



This table is maintained by the ePay Switch and downloaded 
to the ESP Statement Origination Workstation and ESP 





• 

Field 


type 


^- * i " ■■ 1 


Key 


Template Number 


Text 8 


A unique Visa-assigned number identifying 
the Statement Template. *T* & 7 digits. 
E.ff.:T0040456 


Key 


Template Version 

Number 


Text 4 


A Visa-assigned number identifying a 
version of the Statement Template. 4 
digits. E.2.; 1056 


Key Dec 


Effective Date 


Date 


Required date 




Expiration Date 


Date 


M ay be Null 




SSP ID 


Text 7 


*B W & Unique Visa-assigned number 




UBFBillerlD 


Text 12 


Unique Visa-assigned number 




Status Flag 


Textl 


"A": Number Assigned but no Template 

"E": Template Certification Error 

"0": Template On Site (SGen only) 

"P": Template Pending Certification 

"R": Download Requested (SGen only) 

*S n : .Template in Service 

T: Template in Test Service 

"X"; Production Error ! \ 



O 

a 



m 



Statement Data 

a. SLR - Statement Legacy Records 

The records sent to the SSP by a Statement Originator to generate 
Statements for a given Statement Cycle Date. 

SLR records are split into two streams by the SSP: those for 
Customers whose Statements are to be printed, and those for 
Customers whose Statements are to be delivered by the ESP Service. 

Note that for the pilot* all Statements delivered by the ESP Service 
will also be printed. In addition, some Customers may elect to have 
their Statements both printed and delivered electronically. 

b. SAR - Statement Legacy Records, Augmented 

To be processed by the ESP System, Statement Content Records must 
contain all of the data defined by the Statement Descriptor (see page 
42). 

Any of this data not supplied by the Statement Originator must be 
added by the Statement Service Provider (SSP), much of it from the 
Customer Data 

SSP Customer Profile Table (see page 39). 
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This data may include: 

• Template ID = Template Number & V & 

Template Version Number 

• UBF Bitter ID 

• CSPID 

• CBAN 

• Statement Cycle Date 

• Late Payment Date 

SAR records will be passed to the ESP Statement Originating 
Workstation in the form of comma-separated files (CSV) for 
processing. 

72 c. SCR - Statement Content Records 

y I 

These are SAR records which have been re-packaged for 
"i . transmission to The ePay Switch, according to the definitions in the 

S Statement Template, into comma^delimited records for optimal 

y transmission efficiency. They are loaded into SQL tables by the ESP 

O Statement Generation Workstation. 

a 

iU d. Statement Descriptor 

08 

p The minimum data required by the ESP System to be included with 

a Statement 

U! This data is used by the CSP to generate a Mini Statement for the 

» Customer and to allow the Customer to pay the Statement through 

M= the ePay system. 

~ Other and associated sets of Descriptor variables will be added in 

~f response to Statement Originator demand. 

m 
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Each record has the following fields (Note that since this is a comma- 











Key 


Template ID 


Text 


Template Number & V & Template 
Version Number 


Key 


CBAN 


Text 




Key Dec 


Statement Date 


Date 






CSP Account Number 


Text 


How the CSP knows the Customer 




UBFBiUerW 


Text 






Late Payment Date 


Date 






Statement Delivery 

Notification Flos 


Yes/No 






Customer Name 


Text 






Customer Address 1 


Text 






Customer Address 2 


Text 






Customer City 


Text 






Customer State 


Text 






Customer Country 


Text 






Customer Postal ZIP Code 


Text 






Statement Type 


Text 1 


"A" =s> Advisory Message 

"I* «> Invoice, 

"S" => Account Summary 




Message Type 


Text 


Advisory Message Only 




Message Text 


Text 


Advisory Message Only 




Sender Name 


Text 


Advisory Message Only 




Sender Title 


Text 


Advisory Message Only 




Sender Address 1 


Text 


Advisory Message Only 




Sender Address 2 


Text 


Advisory Message Only 




Sender City 


Text 


Advisory Message Only , 




Sender State 


Text 


Advisory Message Only . 




Sender Country 


Text 


Advisory Message Only 




Sender Postal Code 


Text 


Advisory Message Only 




Sender Telephone 


Text 


Advisory Message Only 




Sender Fax 


Text 


Advisory Message Only 






Text 


Advisory Message Only 




Total Amount Due 


Currency 


TnvniM Onlv 




Minimum Amount Due 


C\\ i rTfin rv 


Invoice Onlv 




Past Due Amount 




Invoice Only 




Current Charges 


Currency 


Invoice Only 






Currency 


Invoice Only 






Currency 


Invoice Only 




Credits & Adjustments 


Currency 


Invoice Only 




Previous Payment _ 


Currency 


Invoice Onlv 




Previous Payment Date 


Date 


Invoice Onlv 




Payment Due Date a 


Date 


Invoice Only 




Late Payment Date 


Date 


Invoice Only 




Current Balance 


Currency 


Account Summary Only 




Previous Balance 


Currency 


Account Summary Only 




Deposits & Investments 


Currency 


Account Summary Only 




Withdrawals & Debits 


Currency 


Account Summary Only 




Service Charges 


Currency 


Account Summary Only 




Interest & Dividends 


Currency 


Account Summary Onlv 
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Previous Statement Dote 


Date 


Account Summary Onlv 




Account Description 


Text 


Account Summary Only 




Current Period Yield 


% 


Account Summary Only 




Year to Date Yield 


% 


Account Summary Only 



e. INF - Statement Index 



o 
m 

M 

i 
m 













Statement Descriptor 




oee statement uescnptor , auove 




Status 




ForJSSPuse only. 

Used during Statement Generation to 
control the processing of the Statement. It 
is one of the following: 

• Awaiting Processing 

• Awaiting Template 

(from ePay Switch) 

• In Generation Queue 

• Template Error 

• Data Error 

• Generated 

• Archived 




Fully Rendered 

Statement 
PDF File Name 




for ESP & CSP use 




Generation Date 


Date 


Date that the Statement was generated. 




Pull Date 


Date 


Date that the GSP took delivery of Statement 




Push Date 


Date 


Date that Customer downloaded Statement 



f . Statement Download Log 

If a Statement Originator has set the Statement Delivery Notification 
Flag on the CSP Template /Originator Table {see page 30) via the 
UBF t 6r on the Statement Descriptor (see page 42); an ADV message 
is sent to the ESP Statement Origination Workstation each time a 
Statement is Pulled, Pushed, or Pulled & Pushed by the CSP, 
These messages are generated as part of EndnfiBay Processing (see 
page 25). 



i. Pull 

The CSP Pulls a Statement by issuing the Statement 
Download Req: Pull All ADV to receive and manage all 
available Statements. 

See Statement Batches Solution on page 72. 
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Push 



IH 
"0 
H 

o 

m 

n 

o 
m 
m 

Q 
0) 

m 



The CSP Pushes a Statement by downloading it to a 
Customer, 

Sending this ADV is REQUIRED when the CSP chooses the 
Statement Batches Solution. 

iii. Pull & Push 

The CSP can Pull & Push at the same time. The Statement 
Download Req: Pull & Push ADV is used to request 
Statements one at a time. 

See The Individual Statements Solution on page 71. 



■.. *.. . • =i 




Type ^ 




Key 


SSPBillerlD 


Text 12 


S£P-assigned number, unique for SSP 


Key 


CBAN 


Text 12 


How the Statement Originator knows the 
Customer 


Key Dec 


Payment Due Date 


Date 


Payment Due Date of Statement 




Generation Date 


Date 


Date that the Statement was generated. 




Pull Date 


Date 


Date that the CSP took delivery of Statement 




Push Date 


Date 


Date that Customer downloaded Statement 



Transmission Data 

a. Transmission Index 



Si 



For each Statement Content Record Transmission from SSP to CSP f 
a Transmission Index is sent to the ESP Archive mailbox. 

The Transmission Index is used by ESP Archive to determine which 
transmission contains an individual Customer's Statement. 











Key 


Template ID 


Text 12 


Template # + V + Template Version # 
E.e.:T0040456v0051 


Key 


CBAN 


Text 12 


How the Statement Originator knows the 
Customer . 


Key 


Statement Cycle Date 


Date 












Alt Key 


SSP ID 


Text 7 


SSP ID + Transmission Number form 
unique key 


Alt Key 


Transmission Number 


Long 






UBFBUlerlD 


Text 12 


Unique Visa-assigned number 




CSP ID 


Text 7 


"C & Unique Visa-assigned number 




Record Count 


Integer 


Number of records in this Transmission 
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b. Transmission Log 

For each transmission sent by SSP t CSP, or the ePay Switch, a 
Transmission Log Tecord is generated. 



This Log kept by the transmitter and is used to detect duplicate 
transmissions. 





Meld 




Comment* 


Key 


Destination 


Text 


^To^line of mail message 


Key 


Title 


Text 


From "Subject* line of mail message 


Key 


Hash 


Long 


Hash total for message 




Transmission Number 


Long 






Transmission Date 


Date 






Record Count 


Integer 


Number of records in this Transmission 




3=5 
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E. ESPs Processes 



■TPL 



Visa's ESP 

Template 

Authoring 



1 . The ESP Template Authoring Workstation 

The ESP Template Authoring Workstation is used to \ 
generate and maintain Statement Templates. It is 
operated by the SSP in conjunction with the ESP 
Statement Origination Workstation. 

It is a. Visual Basic program which calls Microsoft 1 g | Workstation 

Access to define and update the Access Report and 
Q SubReports that make up the Statement Template. Ml Template 

y) development, including SAR Stream Parsing and Report definition is done 

=g using Access. 

H See page 15 for a description of the contents of the Statement 

O Template. 

CP 

q Generation of a new Statement Template will include the following steps: 

C3 a) Request a new Statement Template Number from the ePay 
rU Switch. 

£0 

S b) Define the Statement Content Tables: the tables and their fields 

needed to store the data of the Statement This is done using an 
ft Access Wizard to generate Access Tables (Development may be 

m deferred). 

Li Statement Content Tables' names contain the Statement 

£3 Template Number and the Template Version Number of the 

Q Template where they were defined. 

For example, Template T1234667v0123 may contain tables 
iO T1234567vG123, T1234567v0100JService, T1234567v0020JVTT, 

m Ti234567v0003_MCI, etc. 

Table T1234567v0099jService would be obsolete and 
automatically deleted from ESP Statement Generation 
Workstations when its last data is purged. 

c) Map the SLR Stream to ttie Statement Content Tables. The VB 
program reads the Access Tables and shows a Form which allows 
the user to define the mappings via drag-and-drop, depending 
upon the type of SAR Stream (SQL Table, Fixed-length, 
Delimited, or Print Image) (Development may be deferred). 

d) Generation of the Transmission Format mapping is automatic 
(Development may be deferred). 

e) Enter both typical and pathological Test Data. These data will 
be used to develop and test the Statement Template. Different 
conditions can be developed with data for several different 
months. 

See ESP Test Mode on page 71. 

a) Write the Access Report, using the Test Data to verify that the 
Report meets the Statement Originator's expectations. 
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b) Place the new Statement Template onto Test Service with the 
ePay Switch (ref: Statement Template in Test Service ReqADV 
on page 36). If the Switch reports any errors, resolve them and 
re-load. 

c) Sign-on to the various CSP Test Accounts and terminate and 
activate the Statement Examine the test results. 

d) Once the Template produces the required results, place the new 
Statement Template onto Service with the ePay Switch (ref: 
Statement Template in Service Req ADV on page 36). 

Maintenance of existing Statement Templates is done in essentially the same 
r way. 

^ a. Data Stored 

H The current Statement Template MDB File, Statement Stationary , 

Q and any other binary resources needed for Statement generation, 

8* such as fonts* Generic Enclosures/etc. In addition, a copy of the 

p Standard Template should be kept on hand. 

□ ........... " 

Hi b. Processes 

CD " 

p i. Request a new Statement Template # from the ePay Switch. 
J This will be done via the ESP Statement Origination 

llf Workstation. 

e ii. Remove a Statement Template from Service. This will be 
M= done via the ESP Statement Origination Workstation. 

iii. Display a Statement in final form from the test data. 

2 iv. Define the SAR Parsing Table. 

^5 v. Define the Transmission Parsing Table (will he automatic). 

yi. Assemble the Statement Resource Set,' including the 
. Statement Stationary. 

vii. Define the Report and SiibReports. 

viii. Place a Statement Template into Test Service. This will be 
done via the ESP Statement Origination Workstation. 

ix. Place a Statement Template into Service: This will be done 
via the ESP Statement Origination Workstation. 

x. Place a corrected version of a Template into Service. 



c. Hardware 

i. Pentium PC with 32 mB RAM, 2gB hard disk, floppy, backup 
device, CD-ROM, 28.8 kbs modem, keyboard^ mouse, 17" 

monitor and sound sy stem. ^ 

ii. LAN Connection with ESP Statement Origination 
Workstation. 
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d. Software 

i. Operating System: Windows NT Workstation. 

Winl6 operating systems such as Microsoft Windows 
for Workgroups® are not acceptable, since they cannot 
run the software needed. 

ii. Microsoft Access v7.0. 

iii. Desktop Publishing program capable of generating Statement 
Stationary and bitmaps. 

CorelDRAW and Micrografx Designer vector-based files can 
r] be used by Access directly and will both save transmission 

y^i size and improve final appearance. 

iv. Adobe Exchange® v3.0 

q v. Visa's ESP Template Authoring Workstation software. 

□ 2. The Standard Statement Rendering Tool 

JjHj Software designed to generate a Statement using the Template, and data 

lz from one of four sources: 

m 

p 1. Test data from within the Template, 

=3 2. "Production" data from our SQL Server database on the 

ill Statement Generating Workstation, and 

3. "External* data residing in aft ODBC compliant database under 
the control of a CSP Or SSP*s Customer Service Group, 
Q 4. Archived data residing on a CD; 

This tool is part of the ESP Template Authoring Workstation, the ESP 
S Statement Origination Workstation, and the ePay Switch. 

y 5 Given a Template ID, CBAN, and Statement Cycle Date, it will generate a 

Full Rendered Statement PDF File and display it to the operator, using the 
same engine to generate the PDF File as is used in the ESP Statement 
Generation Workstation. 

The operator of the ESP Template Authoring Workstation uses this tool to 
certify new Templates. The Statement Originator can use it for Customer 
Support calls; Visa Research can use i iti lfi conjunction with the ESP Archive 
data store, to re-create atrjr Statement ever passed through the ESP System 
(subject to data availability)^ v 

3. The SSP's System 

The SSP's System will be responsible for two new 
functions: 

• Provide SAR Stream data for Statements to be ^ 
processed by ESP (as defined by the Statement _ , . 
Originator and the Customer), with necessary bSy * s y stem „ 
header information. 

• ReceiveA^wun; Messages (ADV) from theBS •• • v - 
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ESP Workstation, 

Note that The SSFs System is outside the scope of the ESP Project. 
It is the property of the SSP, not Visa. 

LAN or other connection is transparent to the operation of Visa's software, 
since the interface consists of the exchange of ASCII^flag files" only. 

Verification of "Customer Statement Delivery Req" and "Customer Statement 
Delivery Termination Req'ADV messages is controlled by the Customer Sign 
Up field of the SSP on page 29: 

• "A* means that all Customers can sign up.. 

• "B" means that SSP will confirm Customer sign up verification. 



m 

6 
m 
a 

— * 

m 
m 
q 

m 



m 



a. 



Data Stored 



Statement Legacy Records (SLR). Received from Statement 
Originator. Only those SLR's indicated by entries in the 
Customer Profile Table are included, (see page 41). Some 
Statements are removed from the main print stream, and 
some are duplicated there, depending upon values in the 
Customer Profile. 




ii. Statement Legacy Records, Augmented (SAR). Produced 
from SLR, using Customer Data 

SSP Customer Profile Table (see page 39) and Template Data 

Template Index Table {see page 41), 

v. Customer Profile (as described on page: 29, but using SSP 
Bitter ID 9 instead of UBF Bitter ID). 

vL Template Data 

Template Index Table (see page 41). 

viii. Administration Messages, Visa Format (ADV). 
(see page 28). 



Processes 



Receive SSP Customer Profile Table and Template 
Index Table from ESP Statement Origination 
Workstation. 

This new process will be developed by the SSP. The SSP 
Customer Profile Table cotdd also be maintained by the SSP. 
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ii. Receive Statement OrlgihatorJCrefJTable from ESP 
Statement Origination Workstation. 

This new process will be developed by the SSP. 
III. Receive SLR Records from Statement Originators. 

This is an existing process, and is riot affected by this project. 

iv. Split SLR Records 

Split those SLR Records representing Statements bound for 

~, ESP from the main print stream, based upon the Customer 

)z Profile Table. 

m This new process will be developed by the SSP. 
-4 

q v. Augment SLR Records to SAR format. 

■q This new process will be developed by the SSP. 

□ The details of this process depend greatly upon the format of 

fU the SAR Records and the SSP*s data processing 

£0 environment. 

^ Template J^umber and Template JfersionJ) T umber will be 

p added to each Statement Record Set The 

^ Template_VersionJIumber will be checked by the ESP 

Statement Origination Workstation. 

This new process will be developed by the SSP. 



O 

§ vi. Transfer SAR Records \o ESP Statement Origination 

^ Workstation. 

3^ This will be done in the form of a copy of files to and from a 

given set of subdirectories, either via a network or other fiel- 
transfer medium. 

It is new process will be developed by the SSP. 

vii. Transfer ADV File to ESP Statement Origination 
Workstation. 1 

This will be done in the:same manner as SAR Records. 
It is new process will be developed by the SSP. 

viii. Receive Administration Messages (ADV) 

Receive Administration Messages, Visa Format (ADV), with 
Control Total File from ESP Statement Origination 
Workstation. 

This new process will be developed by the SSP. 
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ix. Send Administration Messages (ADV) 

Send Administration Messages, (ADV), and Control Total 
File from ESP Statement Origination Workstation. 

This new process will be developed by the SSP. 

x. Process Control Total File. 

Report any discrepancies found with actual transmission 
records. 

This new process will be developed by the SSP, 

xi. Receive Operator Messages 

When urgent or routine messages are received (as noted by 
"Pass on to SSP" comments), the SSP's operator must 
perform some action. 

These messages will be handled by a modular process, which 
can be interfaced to an e-mail system (via MAPI), console 
messages, or some other means of notifying the SSP's 
Operators. 

xii. Process Administration Messages (ADV) 

This new process will be developed by the SSP. 

(a) Receive ADV: Customer Statement Delivery Req 
Request Statement Originator's OK 

If Statement Originator rejects then . 

Return Customer Statement Delivery Nak 

with error message 
Else If this is a SSP's Test Customer Account 

Return Customer Statement Teat Delivery Ack 
Else Return Customer Statement Delivery Ack 
End If 

(b) Receive ADV: Customer Statement Delivery 
Termination Req 

Request Statement Originator's OK 
If Statement Originator rejects then 

Return Customer Statement Delivery Term Nak 
with error message 
Else Set Termination Date in Customer Profile 

Return Customer Statement Delivery Term Ack 
End If 

(c) Query Statement Download Log or 

Receive ADV: Statement not Pushed by Due Date 

Take appropriate. Customer Service action. 

c. Hardware 

Any: PC, minicomputer, mainframe, or combination. 
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d. Software 

i. Any LAN that can communicate with Windows NT Server. 
e.g.: UNIX TCP/IP, IBM SNA®, Novell Netware®, Windows 
NetBEUI®, Appletalk®, DECnet®, etc. 

ii. Any operating system that can copy files to and from a given 
subdirectory on a Windows NT Server. 

4. The ESP Statement Origination Workstation 

The ESP Statement Origination Workstation esps^'oh^ sar 

^ performs three main functions: it passes Template wcH utation 

hj transactions between the Template Authoring WS [f|j]U- • JV 

and the ePay Switch, it processes an SAR Stream and tpl, r=^L " 
y passes it to the ePay Switch, and it passes and a 

H processes Administration Messages. 

O AUV tpl; 

IP An ESP Statement Origination Workstation is ; 

P identified by an SSPJD. If the same Statement 

^ Service Provider is operating from more :than one site, with more than one 

Statement Origination Workstation, then two separate SSPJDs will 

have to be used. In addition, each Statement Originator is identified by a 
2 UBFBiller ID. If they are originating Statements from more than one SSP 

site, then they will need more than one UBFBiller ID, 

Ms! 

m a. Data Stored 

H i. Each current Statement Template (*.mdb file) defined for the 

O SSPs.Statement Originators must be kept for local 

O processing. 



■n 




ii. Template Data 

Template Index. Table (see page 41). Used to add 

Template Jfersionjfumber to SAR Records. 

iv. Statement Originator Cross-Reference Table (see page 28), a 
cross-reference between the SSP's Bitter JD*s and Visa's 
UBFBiller ID'S. Used to reformat SAR Records for 

, transport. 

v. The Customer Data 

SSP Customer Profile Table (see page 39), maintained by this 
workstation. 

vii; SAR Records awaiting parsing and transport 

viii. Statement Content Records^ parsed from SAR Records and 
awaiting transport 

ix. Control Total File containing transmission control totals for 
auditing. 
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b. Processes 

Notes: Req = Request, 

Ack = Acknowledgment , 

Nak ss Negative Acknowledgment 

i. Receive SAR Recordsirom the SSP's System. 

Convert SSP's Biller ID to UBF Biller ID. See page 41. 

Current plans call for this to be one of the following: 

• When SAR Records are presented in SQL Tables, they 
£ are copied into files of comma-delimited records. One file 

for «ach Statement Content Table, with the table name as 
==, filename, and with one variable-length record for each 

table record. 

0 An accompanying Control Total File, consisting of one 

01 record for each of the data files, showing record count 

O and hash totals, must be included. This file's records will 

0 be compared against the files received, and any 

fU differences will be reported. 

jjf o When SAR Records are in other formats, the records 

: ^ themselves are presented. Transmission Control Files 

will have to be worked out with each SSP. 



These files will be copied into a given subdirectory on the 
Workstation. 



il Parse the SAR RecordslnXo Statement Content 
jp Records for Transmission. 



Si 



This will be done using, the SAR Parsing Table within the 
Statement Template. It is an entirely table-driven process, 
with NO code specific to the Statement Templates being 
processed. 

In the case of SQL Table-based SAR Records* this will mainly 
consist of adding the Template_Version_Number and UBF 
Biller ID and CSPJD from the SSP Customer Profile Table. 

Since the SSP has a vested interest in the fidelity of the 
Statement (after all^ the Statement Originator is his 
Customer !), any labor-intensive or sophisticated processing 
should be here, rather than at the ESP Statement Generation 
Workstation. 

SAR Records for a single StatementJTemplateJt will be 
sorted and processed in order of CSPJD. 

Ill _ Collect Statement Content Records by Destination 

As Statement Content Records are received, they are copied 
to ASCII file sets, one set for each destination CSP. Each set 
consists of one file for each Statement Content Table in the 
set. 
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When a pre-determined number of Statements (say 100) are 
represented in any one file set, or when Statement Content 
Records are received for a new Template, that set is 
transmitted to its destination CSP, via the ePay Switch, and 
the ASCII files are emptied. 

Transmitting Statement Content Records to the CSP 
via the ePay Switch. 

Each Statement Content Record Set (i.e.: the records for one 
Statement) take part in three transmissions: the Statement 
Content Record Message, the Transmission Index Message, 
and the Transmission Control Message. 

(a) The Statement Content Record Message 

Each ASCII file of the Statement Content Record Set 
is included in the Message as an Enclosure. 

See the SCR - Statement Content Records portion of 
ESP System's Data Transmissions on page 42. 

Total record counts are added for each file, and a 
hash is performed on the CBAN field of the "main" 
file. 

The CBAN field is chosen for the hash field because it 
is a required field for all Statements - see Statement 
Descriptor on page 42. 

A copy of the Statement Content Record Message is 
sent to mailbox ESPArchivet where it is stored for 
Visa Research. 

(b) The Transmission Index Message 

The Transmission Index Message is a cross-reference 
to the CEANs within a Statement Content Record 
Message. It is used by Visa Research to determine 
which Statement Content Record Message contains 
the Statement data for a given Customer. 

See ihe Complex Administrative Messages portion of 
ESP System's Data Transmissions on page 42. 

(c) The Transmission Control Message 

EVERY message sent via the ePay Switch must 
produce a corresponding record sent to the mailbox 
ESP Transmission Control. In addition, when ANY 
message is read from the ePay Switch, a 
corresponding record must be sent to ESP 
Transmission Control. 

Thus, ESP Transmission Control acts as a 
clearinghouse ofmessages, ensuring integrity and 
timeliness. 

See the Simple Administrative Messages portion of 
ESP System's Data Transmissions on page 42. 
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v. Receive and Process Administrative Messages (ADV) 
from the SSP's System 

A Control Total File will be needed in all cases. 

(a) Receive ADV: Customer Statement Delivery Ack 
Create BS Customer Profile 

Send ADV to CSP 

(b) Receive ADV: Customer Test Statement Delivery 
Ack 

Create BS Test Customer Profile 
Send ADV to CSP 

(c) Receive ADV: Customer Statement Delivery 
Termination Ack 

Update BS ' Customer Profile Termination Date 
Send to Customer 

(d) Receive ADV: 

Customer Statement Delivery Nak 
Customer Statement Delivery Term* Nak 
Send ADV to Customer 

vi. Process Administrative Messages (ADV) from SSP 

(a) Receive ADV: 

ANY "Statement Template ... Request" 
Statements Not Downloaded List 
End-of-Day Transmission Query 
Send to ePay Switch 

vii. Process Administrative Messages (ADV) from ePay 
Switch 

(a) Receive ADV: Customer Statement Delivery Reg 

If Customer Sign Up = "B" then 
Pass on to SSP 

Elself Customer Sign Up = "A" then 

Create SSP Customer Profile record 
Send Customer Statement Delivery Ack 

to Customer 

End If 

(b) Receive ADV; Customer Statement Delivery 
Termination Reg 

If Customer Sign tip = "B" then 
SendtoSSP 

Elself Customer Sign Up = "A" then 

Update SSP Customer Profile record 
Send Customer Statement Delivery Termination 

Ack to Customer 
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(c) Receive ANY "Statement Template ... Ack/Nak" 
ADV 

Send to ESP Template Generation Workstation 

(d) Receive ADV: 

Statement Template Expires next Month 
Statements Not Downloaded List 
End-of-day Statement Transmission List 
Report to operator. 

(e) Receive Transmission Received from ePay 
Switch ADV 

Delete Message from "Sent" mailbox. 

viii. Pass Statement Templates and Admin. Messages from 
The Template Authoring Workstation to the ePay 
Switch, 

This will be a simple bi-directional pass-through, with the 
exception that a copy of all Templates currently in service for 
the SSP will be retained. 

Each receipt and transmission will be recorded in the Control 
Total File. 

ix. Send Administrative Messages (ADV) to ePay Switch 

Transmissions will be made at pre-detennined intervals (e.g.: 
once a day, when 100 messages have accumulated, etc.). 

x. End-of-Day Processing 

See End-of-Day Processing on page 25. 

Local traffic control reports will be generated. Details of 
their design have yet to be determined. 

xi. System Management Functions 

All messages generated by the ESP System for attention of 
SSP Operations will be sent to a modular error handler. This 
error handler can be configured to deliver its messages in one 
of several different ways: by the SSP's internal e-mail, by 
FAX, or to the ESP Statement Origination Workstation 
monitor. 

c. Hardware 

i. Windows NT "cluster" with one or more Intel-based servers 
to execute Visual Basic code. 

May range from a single Pentium® PC to a group of heavy- 
duty Windows NT servers. A significant portion of the server 
cluster must be Intel-based to execute Visual Basic code. 
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A minimum system would consist of: Pentium Pro PC, 96mB 
of RAM, 8gB RAID 5 disk array, CD-ROM, keyboard, mouse, 
17" monitor, sound system, backup hardware, Windows NT 
compatible communications hardware (e.g.: telephone, 
modems, ISDN lines, dedicated lines, etc). 

ii. LAN connection to SSP's System 

hi. Connection to ESP Template Authoring Workstation. 

May be LAN or "sneaker-net". 

iv. Microsoft Exchange Server remote connection to ePay 
Switch. 

d. Software 

i. Windows NT Server. 

ii. Visa's ESP Statement Origination Workstation software. 

iii. Microsoft Exchange Client 

iv. Microsoft SQL Server. 

v. Adobe Exchange. 




ePay Switch 



The ePay Switch 

r 

The ePay Switch is a Visa resource, and will be 
initially operated from Visa's San Mateo facilities. 
Unlike the ESP Template Authoring Workstation 
and the ESP Statement Origination Workstation, it 
deals with ALL SSP's, and ALL CSPs. 

It has four primary tasks: 

i. Move Statement Content Records 
from SSP to CSP. 

Move Administration Messages (ADV) from CSP and SSP 
and visa-versa. 

Store, validate* and log Statement Templates, and supply 
them to Statement Generation Workstations. 

iv. Move Payment Messages from ePay BBWS and OWS 

Workstations to Visa's Base II and visa-versa (outside the 
scope of the ESP Project). 
This must be done with the highest standards of integrity and reliability. 



n. 



in. 



a. Hardware 

i. A Windows NT "bluster* : 

The ePay Switch will have significantly higher 
communications throughput than any other part of the 
system, since it will serve the entire ePay system, not just 
ESP. 
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A significant portion of the cluster will have to be Intel-based 
servers for the execution of Visual Basic code. 

ii. Connection to ALL ESP Statement Origination Workstations, 
ESP Statement Generation Workstations, and ePay BBWS 
and OWS Workstations. 

hi. LAN connection to a Visa Base II VAP vl0.2 or higher 
(outside the scope of the ESP Project). 

b. Software 





i. 


Operating System: Windows NT Server. 


m 


ii. 


Microsoft Exchange Server® 


iii. 


Visual Basic run-time with MAPI connection to the Exchange 
Server, and with Jet or Microsoft SQL Server® database. 


0 

m 


iv. 


Visa's ESP ePay Switch and ESP Template Management 
software. 


0 

m 


c. Data 


Stored 


ffl 


i. 


All Statement Templates defined in ESP (see page 15). 


m 


ii. 


Universal Biller File (UBF) (see page 28). 


iii. 


Statement Originator Xref Table (see page 28). 


5 

M> 
O 


iv. 


Template Data 


Template Index Table (see page 41). 


P • 


vi. 


Control Total Files for all traffic routes. 


y3 


vii. 


All messages sent or received, in off-line storage for 180 days. 


m 


d. Processes 

Notes: Req = Request, 

Ack = Acknowledgment , 

Nak = Negative Acknowledgment 




i. 


In conjunction with ESP Template Authoring 
Workstations, via ESP Statement Origination 



Workstations: 

(a) Receive ADV: New Statement _Temp late_# Reg 
Generate & record a new Statement_TemplateJt. 
If OK then 

Return New Statement_Template_# Ack 

with new Statement_TemplateJt to SSP 

Else 

Return New Statement_TemplateJt Nak to SSP 
End If 
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(b) Receive ADV: Statement Template in Test 
Service Req 

Check Template. Note that this can be a new 
updated Template. This will be a largly 
manual process, involving checking the 
Template for syntactical and functional 
correctness, not for making editorial 
comments. 

In some instances, the turnaround time for 
this checking procedure will be critical to the 
successful delivery of Statements. In those 
cases* Visa has pledged to expedite this 
process. 
If OK then > ! 

Move Template to Test Download Area 
Return Statement Template in Test Service Ack 

to SSP 

Else Return Statement Template in Service Nak 

with Errors Found to SSP 

End If 

(c) Receive ADV: Statement Template in Service 
Reg 

Check Template. Note that this can be a new 
updated Template (see note above re 
Checking a Template). 

If GK then 

Move template to Download Area 
Return Statement Template in Service Ack 

to SSP 

Else Return Statement Template in Service Nak 

with Errors Found to SSP 

End If 

(d) Receive ADV: Stmt Template Deactivate Reg 
If Date in future then 

Set Template Expiry Date 

Return Statement Template Deactivate Ack to SSP 
Else Return Statement Template Deactivate Nak 

to SSP 

End If 

(e) Receive ADV: Statement Template Expires next 
Month 

Send Statement Template Expires next Month to SSP 
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ii. In conjunction with ESP Statement Origination 
Workstations: 

(a) Transfer Statement Content Records, 

(b) Transfer the following Administration 
Messages (ADV) to ESP Statement Generation 
Workstations: 

Customer Statement Delivery Ack I Nak 
Customer Statement Delivery Term Ack I Nak 
Statements Not Downloaded Since Date Query 

(c) Receive ADV: Records received from ePay 
Switch 

U? Receive ADV: Records sent to ePay Switch 

Save record counts for auditing 

i 

D iii. End-of-Day Processing 

m 

□ See End-of-Day Processing on page 26. 

y System-wide traffic control reports will be generated and 

a w portions will be sent to the various workstations. Details of 

M their design have yet to be determined. 

o 

,j=i Billing reports will also be generated. 

e Iv. In conjunction with ESP Statement Generation 

L Workstations: 



~ (a) Transfer Statement Content Records. 

U 

,0 (b) Transfer the following Administration 

,n Messages (ADV) to ESP Statement Origination 

rf* Workstations: 

Customer Statement Delivery Req or 
Customer Statement Delivery Termination Req 
Statements Not Downloaded Since Date List 

(c) Receive ADV: Stmt Template Download Request 
Send Template 

(d) Receive ADV: Records received from ePay 
Switch 

Receive ADV: Records sent toePay Switch 
Save record counts for auditing 

v. Download UBF from Base II 

Only an extract of the fiill UBF is downloaded. 

vi. Transfer Payment traffic for the Customers' Bank's 
ePay Origination Work Station and the Billers* Bank's 
ePay BB Workstation. 

Note that this is outside of the scope of the ESP Project 
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vii. Mailboxes: 

• One for each SSP ID = SSP ID (starts with a B"). 

• One for each CSP ID = CSP ID (starts with W C W ). 

• ESP Statement Template Control 

• ESP Archive 

• ESP Transmission Control. 

• ESP Statement Templates - a public folder for downloads. 

• All CSPs for Template 

viii. Mall Robots 



C 

m 

H 

O 

m 
p 
o 

m 
m 



Mail Robots (Visual Basic programs with MAPI interfaces) 
watch certain mailboxes and process any messages arriving 
there: 

• All CSPs for Template 

Watches All CSPs for Template mailbox, and forwards 
message to all CSPs who have downloaded that 
Template. 

• Statement Template Control. 

Watches Statement Template Control mailbox. 

• Reconcile Transmission Control Files. 

Watches Transmission Control mailbox. Produces end- 
of-day reports on transmissions received and passed on. 

• ESP Archive. Stores all Statement Content Record and 
Admin Messages transmissions for research. 



The ESP Statement Generation Workstation 



m 



The ESP Statement Generation Workstation 
provides the CSFs Home Banking System with the 
Statement PDF Files and associated fielded data 
necessary to display a Statement on the Customer's 
PC. It also processes Administrative Messages and 
transfers them to the ePay Switch. 

a. Data Stored 




Visa's Statement 

Generation S q^ 
Workstation j^y 



1. Statement Index (INF) - SQL 
Table 

One row per Statement. Contains Statement Index File data. 
See page 42. 

Ii. Statement Content Records (SCR) - SQL Tables 

Note that the Customer can request Statements from prior. 
Billing Cycles - for a predefined period of time (say 6 
months). 

This data is stored in tables within a Microsoft SQL 
Server® database, not within the Template, an Access 
database (*andb file). Each Statement Template has one or 
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more different tables associated with it, so several thousand 
tables may be involved. 

See page 39. 

ill. Fully Rendered Statement PDF Files 

Statements prepared for delivery to the Customer will be 
either fully rendered in a single PDF File, or will be shipped 
in Statement/Stationary pairs for caching and merging on 
the Customer's PC. 

Initially, fully rendered PDF files will be produced because 
the technology to merge Statement/Stationary pairs on the 
Customer's PC is not yet in hand. This can be globally 
^ changed quite easily, once the Customer PC software has 

been developed. 

Q One PDF per file. Filename is stored in the Statement Index. 

2 See page 7. 

3 

nJ 



m 



iv. Templates 



W All Templates received from the ePay Switch. Each 

Q Statement Template will consist of an MDB file and one or 

~3 more binary resource files such as bitmaps. These will be 

U1 stored together in a separate subdirectory for each Template. 

* It is expected that a large CSP could accumulate several 
thousand Templates. 

p See page 15. 

*p v. Template List 



An ASCII version of the Template Data 

Template Index Table (see page 41), containing a row for 
each Template in Service, whether on-site or not* 

vi. Optional Generic Enclosures index *- SQL Table 
viL Optional Generic Enclosures PDF Files 

vill. Customer Profile Table 

See page 29. 

Ix. Control Total File 

Contains transmission control totals for auditing. Generated, 
here and transmitted to the ePay Switch. 



95000.952 



Appendix 1 



Express Mail #EM300602468US 



Page 64 



ESP System Architecture 



b. Processes 

Notes: Req - Request, 

Ack = Acknowledgment , 

Nak = Negative Acknowledgment 

!. Receive Statement Content Record (SCR) Data 

Batches are received from the ePoy Switch t parsed, and 
stored. 

This will be done into SQL tables It will be a high-volume 
^ batch process, done by an optimized Visual Basic program 

w with little screen interaction. 

U) ■ -■ 

V ii. Generate Statements In Batch Mode 

H 

q All Statements received will be processed in batch mode. 

2 This will be done by a Visual Basic Program which checks 

2 the Statement Index fable for newly received Statements. 

fy See Figure 33 - Generating the Fully-Rendered Statement on 

gg page 4. For each new Template, the following processing is 

r=i done: 

fee? 

*D 1. If the Template is not available locally, it is fetched 
Ul from the ePay Switch, any new fonts are loaded, and 

= any other binary resources are extracted. 

2. All Statements for that Template are generated, as 
follows: 



O 



jj3 • The Customer-Specific Mandatory Statement is 

^ generated via calls to Access as an OLE 

gi Automation Server, and is output as a PDF File. 

At the same time, the PDF Merge Control Table 
(see page 16 ) is generated for this Customer's 
Statement. This is a list of PDF Files which must 
be appended' to form the Fully Rendered 
Statement PDF File. 

The first entry in this table is usually a The 
Interactive Page PDF File (see page 12). 

• The PDF files specified in the PDF Merge Control 
Table are concatenated by Adobe Exchange, also 
called as an OLE Automation Server. 

Once this is done, the Status of the Statement is upgraded to 
u GenerateoT. 

As volumes increase, Statement Generation will be off-loaded 
to dedicated Windows NT Workstations, attached to the ESg 
Statement Generation Workstation by LAN. The Distributed 
Two-Phase Commit feature of Microsoft's SQL Server will 
make this possible. 
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iii. Purge Statements 

Each day, all Statements more than x months old are purged 
from the system. 

iv. Receive Administrative Messages from CSP 

(a) Customer Statements Available Query 

Query Statement Index to ah ASCII file. 

Selection criteria is UBF BUler ID and CBAN OR 
CSP Account Number, 1 

C Return "Customer Statements Available Lisf 

ifl message, pointing to ASCII file. 

y (b) Statement Download Request: Pull All 

Q Send pointers to ALL Statements that have not been 

§1 already downloaded. Record Pull Date for all of these 

3 Statements, 

y (c) Statement Download Push 

^ ADV contains Template ID, CBAN, 

j*j and Statement Cycle Date. 

%D Record Push Date for of this Statement 

~ 5 If the Statement Delivery Notification Flag of 

s t SSP (see page 29) is set 

U OR the Statement Delivery Notification Flag of 

y Statement Descriptor (see page 42) is set 

U Then 

*B Generate Statement Pushed ADV 

J (d) Statement Download Request: Pull & Push 

Send pointer to a SINGLE Statement. The CSP is 
replying to a Customer's request and will Pus/i the 
Statement immediately. Record Pull Date and Push 
Date for of 'this Statement. 

ADV contains Template ID, CBAN, 

and Statement Cycle Date. 

If Statement has been generated then 

Return Statement Download Pointer" 

message, pointing to 
& Fully Rendered Statement PDF File. 

If the Statement Delivery Notification Flag of 
S3F (see page 29) is set 
OR the Statement Delivery Notification Flag 
of 

Statement Descriptor {see page 42) is set 

Then 

(Generate Statement Pushed ADV 
Endlf ' 
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Else If Statement PDF File has been purged, but the 
data is still available then 

Regenerate the PDF File 

Return "Statement Download Pointer 1 * 

message, pointing to 
a Fully Rendered Statement PDF File. 

If the Statement Delivery Notification Flag of 
SSP (see page 29) is set 
OR the Statement Delivery Notification Flag 
of 

Statement Descriptor (see page 42) is set 
r Then 

Generate Statement Pushed ADV 

^ End If v 

y 

p Else Return "Statement Download Nak n message 

^ with an error message. 

□ (e) Optional Generic Enclosures Download Request 

jjj If the Optional Enclosure PDF File is available then 

jjjf Return "Optional Generic Enclosures 

J Download Pointer" 

O Else Return "Optional Generic Enclosures Download" 

Nak message with an error message. 

^ E (f) Customer Statement Delivery Req 

M= Edit options selected against CSP (see page 29). If 

n OK, Pass on to ePay Switch, If NOT OK, report error 

p to Visa - this is contrary to ESP Operating 

■j% Procedures. 

MS (g) Receive other ADV from CSP 

~ Pass on to ePay Switch. 

v. Receive ADV from ePay Switch 

(a) Customer Statement Delivery Ack . 
Update Customer Profile and pass on to CSP. 

(b) Customer Statement Test Delivery Ack 

Update Customer Profile with Tea* Account Flag set 
and pass on to CSP. 

(c) Customer Statement Delivery Termination Ack 
Delete Customer Profile record and pass on to CSP. . 

(d) Transmission received from ePay Switch 
Delete Message from "Sender Archive" mailbox. 

(e) Other "Ack" or "'Nak- ADV 
Pass on to CSP. 
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(f) Statements not Downloaded Query 

Generate and return "Statements Not Download List" 
ADV. 

vi. End-of-Day Processing 

See End-of-Day Processing on page 25. 

Local traffic control reports will be generated. Details of 

their design have yet to be determined. 



Hardware 



A Windows NT server or server cluster. Unlike the other 
portions of the ESP system, the Statement Generation 
Workstation will devote a significant portion of its time to the 
generation of Access Reports. This will require one or more 
Intel-based servers. 

A typical system would include: Pentium Pro PC, 96mB 
RAM, 10 to 50gB RAID 5 disk array, CD-ROM, keyboard, 



t~ mouse 17* monitor, sound system, communications 

2j hardware, backup hardware. 

□ ii. RAS connection to ePay Switch. 

*D ^ LAN connection to host CPS's HBS. 

in 

d. Software 

O i. Windows NT Server. 

ii Microsoft Exchange Ghent 

y2 iii. Microsoft SQL Server®. 

0* i v . Microsoft Access 

v. Adobe Exchange® 

vi. Visa's ESP Statement Generation Workstation software. 



Customers' PC 




PAY, 



The Customer's PC 

Note that Customer's PC is outside the scope of 
the ESP Project. The hardware is the property 
of the Customer and the software is specified or 
provided by the CSP. 

\ \ rnx, 

The Customer's PC communicates with the CSP ^ \ ADC 

either via the Internet, Intranet, or a proprietary stm, O 

network. Proprietary network connections can be opt ^ _ 

either on-line or off-line. 

In all cases, the free Adobe Reader is used to display the Statement. 

Future plans call for downloading -of the Statement i in ? ta "™ tlS ™™ ary 
PDF Sets, with the Stationary PDF FUes being cached on the Customer's 
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PC, This would offer significant performance advantages over downloading 
fully rendered PDF files. 

See Downloading unchanging Statement elements to the Customer's PC is 
Inefficient on page 82 

These plans are made less urgent by advances in Adobe PDF file 
compression and downloading strategies. 

a. Kinds of Customer PC Software 

The following kinds of PC Software systems are anticipated: 
HTLM/Internet, HTML/Intranet, Proprietary On-line and 
Proprietary Off-line. 

i. HTLM/Internet 

This is the standard ]£orld-]£ide-]£eb based system. 

ii. HTML/Intranet 

As for HTML/Internet, but with a private dial-up network for 
added security. 

ijL Proprietary On-line 

GSP*s application software, written to run while connected to 
the CSP^ System. 

iv. Proprietary Off-Line 

CSP's application software, written to run while NOT 
connected to the CSP's System. Data transfer is controlled 
by batch queues, which control transmission once 
communication is established. 

b. Data Stored 

Fully Rendered Statement PDF Files. 
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Processes 

i. Request a list of Statements available for ESP. 



in 

Tl 



m 
□ 
o 
ru 

m 
m 

t f3 



□ 

m 



Notes: 



Figure 9 - A Mock-up of a Statements List 

This is a mock-up of a CSP's offering to its customers, and is outside the scope of 
the ESP System. 

The underlined words are Web links to start or stop downloading of a Statement. 
This design is copied from the local Yellow Pages, Much opportunity exists for 
CSP's to improve on this layout 
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li . Select a new Statement for ESP. 

Hi. Request Termination of Delivery of an existing 
Statement 

iv. Request a list of Statements currently available for 
Downloading. 



W 
V 

6 



■zzxr 

o 
m 



Notes: 



Figure 10 - A Mock-up of a Statement Download Form 

This is a mock-up of a CSi^s offering to its customers, and is outside the scope of 
the ESP System. 

The underlined words are Web links to download a Statement. 
Suzie paid her September Sears statement by check, so the payment is not 
recorded here. Note that recording of ePay payments would be a CSP function 
outside the scope of the ESP System, 

CSPs may choose many other layouts. For example, access historical documents 
may be from another Webpage, reached through a button or menu item. 
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v. Request that a single Statement be Downloaded. 

For a mock-up of a Statement as it could be presented to a 
Customer, see The Statement on page 7. 

vl. Request an Optional Enclosure. 

vll. Request Payment of a Statement 

x This is outside the scope of the ESP Project, 

d. Hardware 

0) Any PC, Macintosh®, or Unix workstation. 

«] e. Software 

O 

If the CSP is WWW based, any web browser that supports Adobe 
i Reader Plug-ins. If the CSP is not WWW based, CSP's home 

=^ banking software, which must support Adobe's Reader. 



8. The CSP's Home Banking System (HBS) 



^ Note that The CSP's Home Banking System is 

^0 outside the scope of the ESP Project. It is the 

property of the CSP f not Visa. 

L The CSP's Home Banking System (HBS) will pass 

Admin. Messages and Statements between the 
p. Customer and the ESP Statement Generation 

^ Workstation. 

d} Visa's ePay System will receive payment, outside the 

pi scope of the ESP Project 

a. Methods of Operation 




CSFm 
Home Banking Server 



Two methods of operation are offered: individual Statements and 
Statement batches. With The Individual Messages Solution, ESP 
provides management of Statements and Optional Enclosures in a 
single, unified manner; while the Statement Batches Solution allows 
the CSP to manage Statements and Optional Generic Enclosures in 
the manner best suited to their needs. 

Please note that the Individual Statements Solution still requires that 
all incoming Statement Content Records be processed in batch mode, 
and that the Statement Batches Solution does not prohibit the use of 
individual Statement requests, especially for prior-period Statements. 

i. The Individual Statements Solution 

Communication between CSP's Home-Banking System and 
the ESP Statement Generation Workstation (SGen) is in the 
form of ADV messages. 
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Queries are generated by the CSP in response to Customer 
requests* 

Since these messages are- originated by the Customer, who is 
waiting for their reply, they must be processed in real time at 
the highest priority. 

(a) The Query 

The following ADVs are used: 

• Statement Download Req: Pull & Push 

• Optional Details Download Req 

• Optional Enclosure #x Download Req 

C Note that u Pull & Push" refers to the fact that the 

■J) Statement is Pushed to the Customer at the same 

TJ timethatitisPaWedby the GSP. 

^ (b) The Response 

CP Responses returned by SGen are in the form of 

p messages containing filenames pointing to files on the 

Q Workstation. 

J The following ADVs are used: 

J • Statement Download Pointer 

U • Optional Details Download Pointer 

y3 • Optional Enclosure ftc Download Pointer 

IJ1 .. 

« ii. Statement Batches Solution 

p Communication between CSP*s Home Banking System and 

p the ESP Statement Generation Workstation (SGen) is in the 

form of ADV messages. * 

^0 SGen's response can he triggered in one of two ways: by 

01 completion of processing of a batch of newly-arrived 

Statement Content Records, or by receipt of & Statement 

Download Req: Pull All ADV. 

' The first trigger is enabled by a parameter in SGen's 
initialization file^ 

(a) The Query 

Queries are generated by the CSP in response to 
Customer requests. The following ADVs are used: 

• Statement Download Req: Pull All 

Note that "Pu//* refers to the fact that the Statement 
is Pulled bytiie CSP. 

(b) The Response 

Responses returned by SGen are in the form of 
messages containing filenames pointing to files on the 
Workstation. 

The following ADVs are returned, one for each item 
currently available but not previously reported: 

• Statement Download Pointer 
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• Optional Details Download Pointer 

• Optional Enclosure #jc Download Pointer 

b. Data Stored 

I. Customer Profile Table. 

See page 29. 

il. ESP Statement Originator Table. 

^ See page 29. 

tfl HI. Fully Rendered Statement PDF Files 

V 

=4 The CSP may choose to store and distribute all Fully 

Q Rendered Statement PDF Files as they are generated, by 

g\ issuing Statement Download Req.PuU All ADVs, or may 

p leave that storage up to the ESP Statement Generation 

p Workstation and issue Statement Download Req: PuU & 

jU Push ADVs when the Customer requests a Statement. 

m 

n c. Processes 



Customer Requests a list of Statements available for 
ESP. 

Generate list from ESP Template /Originator Table (see page 
29). 

Selection criteria is UBFBiller ID and CBAtf OR CSP 
Account Number. 

Customer Selects a new Statement tor ESP. 

Send "Customer Statement Delivery Req n ADV. 

Receive "Customer Statement Delivery Ack n . Inform 
Customer that they are signed up. Update Customer Profile. 

... OR... 

Receive "Customer Statement Delivery Nak n . Inform 
Customer that their request has been denied and show 
accompanying reason. 

Customer Requests Termination of Delivery of an 
existing Statement 

Send "Customer Statement Delivery Termination Request" 
ADV. with Termination Date. •■. 

Receive "Customer Statement Delivery Termination Ack". 
Inform Customer. Update Customer Profile. 

••• OR ••• 



in 



u 



in. 
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Receive "Customer Statement Delivery Termination Nak n . 
Inform Customer that their request has been denied and 
show accompanying reason. 

iv. Customer Requests a Statement 

(a) Method of Operation: The Individual 
Statements Solution 

Send "Statement Download Req: Pull & Push" ADV 
with the following fields: Statement Template #, 
CBAN t & Satement Cycle Date. 

Receive a Fully Rendered Statement PDF File (see 
page 7 for a definition) from the ESP Statement 
Generation Workstation, and pass it on to Customer. 

(b) Method of Operation: Statement Batches 
Solution 

Download Fully Rendered Statement PDF File 
previously received from the ESP Statement 
Generation Workstation, and pass it on to Customer. 

v. Customer Requests Optional Customer-Specific 
Pages. 

(a) Method of Operation: The Individual 
Statements Solution 

Send "Optional Details Download Req n ADV with the 
following fields: Statement Template #, CBAN, & 
Satement Cycle Date. 

Receive a Optional Customer-Specific PDF (see page 7 
for a definition) from the ESP Statement Generation 
Workstation, and pass it on to Customer. 

(b) Method of Operation: Statement Batches 
Solution 

Download Optional Customer-Specific PDF previously 
received from the ESP Statement Generation 
Workstation^ and pass it on to Customer. 

vl. Customer Requests an Optional Enclosure. 

(a) Method of Operation: The Individual 
Statements Solution 

Send ^Optional Enclosure #s Download Req" ADV 
with the following fields: Statement Template #, 
CBAN; Optional Enclosure Number & Satement 
Cycle Date. 

Receive a Optional Enclosure PDFFileisee page 7 for 
a definition) from the ESP Statement Generation 
Workstation^ and pass it on to Customer. 
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(b) Method of Operation: Statement Batches 
Solution 

Download Optional Enclosure PDF File previously 
received from the ESP Statement Generation 
Workstation, and pass it on to Customer. 

vii. Customer Requests Payment of a Statement 

Outside the scope of the ESP Project 
Hardware 

Any: PC, minicomputer, mainframe, or combination. 



T! e. Software 

*4 



i Any LAN that can communicate with Windows NT Server. 

*S " e.g.: UNIX TCP/IP, IBM SNA®, Novell Netware®, Windows 

g NetBEUI®, Appletalk®, DECnet®, etc. 

O ii. Any operating system that can copy files to and from a given 

fU subdirectory on a Windows NT system. 

2 iii. Any software that the CSP currently uses to connect with the 

Customer's PC. 

m 9. Visa's Base II 



Visa's Base II system will be used to transport ePay 
9 Payment Orders between ePayOWS and BBWS 

P Workstations, and to download UBF Files to the ePay 

0 Switch. 

£ Note that, except for the downloading of UBF Files, 

y £ connection to Visa's Base U System is outside the ^ p 

scope of the ESP Project 
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F. Interfaces 

1. ESP Statement Origination Workstation to the SSP's System 

Administration Messages, Visa Format (ADV) and yua . t 

Statement Legacy Records, Augmented :(SAR) are sSILnt fn 

passed between the SSP's System and the ESP *™: 4 

Statement Origination Workstation. f^ff" == 

The SSP's System connects with the ESP Statement rHsT fiSJX,Sj " tem 
Origination Workstation via LAN. 

C The Windows NT software of the ESP Statement Origination Workstation 

m can connect to most LANs in use today, including UNIX TCP/IP, IBM SNA, 

V Novell Netware* Windows NetBEUI, Appletalk, DECnet, etc. 



Two Network Shares provided by the ESP Statement Origination 
— Workstation will be the main form of communication: ToJSSP and 

FromJSSP. Data is passed in A3CII files stored in these subdirectories, or 
y in subdirectories below them. 

Sy A Network Share is a pointer to a subdirectory on a system - in this case, to 

a subdirectory on the ESP Statement Origination Workstation's Windows NT 
Q disk farm. 

jj a. Transport Mechanism 

? Data is passed in ASCII files stored in two subdirectories (To_SSP 

^ and FromJSSP), or in subdirectories below them. Once copied, files 

O are deleted by the recipient. 

o . 

*y i. Security 

y3 

m The SSP will need a Windows NT account with password on 

the ESP workstation. This account will be limited to 
read/execute/delete access for ToJSSP, and write/execute 
access for FromJSSP. 

ii. Interface Control File 

Each subdirectory has an Interface Control File. 

This is a file recording each copy from and copy to performed 
by either party. It is archived by the ESP workstation. 

Row Contents: "From'TW, "SSPTESP", Date-Time Stamp, 
Filename* Record Count, Hash Total (to be 
defined, by file type) 

Filename: Gontrol.txt 

b. ToJSSP 

For either solution, this will contain the following data files, all in 
comma-delimited ASCII format. 



95000.952 Appendix 1 Express Mail #EM300602468US 



Page 77 ESP System Architecture 



I. Interface Control File 

ii. ADV <- Administrative Messages, Visa Format 

See page 30 for a description. 

Filename: ADV_999.txt, where 999 is a sequentially assigned 
number. 

///. Customer Data 
^ 4v. SSP Customer Profile Table 

£n See page 39. 

Filename: Customer.txt 

H 

y v. Template Data 

m 
O 



■¥k Template Index Table , 

J See page 41. This fife is used by the SSP to check the 

ffl Statement Template Number portion of the Statement Descriptor 

O (see page 42). 



Filename: Template.txt 
c. From_SSP 

i. Interface Control Total File 



Hi 

s 

2 

gi II. ADV - Administrative Messages, Visa Format 

See page 30 for a description. 

Filename: ADV_999.txt, where 999 is a sequentially assigned 
■ number. 

HI. SAR - Statement Legacy Records, Augmented 

See page 41. 

Filename: S AR\<CSP ID>. txt E.g.: 
Fro/roSSP\SAR\C1234567,txt 

2. ESP Statement Origination Workstation to ePay Switch to ESP 
Statement Generation Workstation 

This communication path will be implemented as a IMU^ B B 

RAS PPP connection - either dial-up, packet- ^^^(Dpi 

switched, or dedicated. Messages will be transferred ir.X 

to and from a Microsoft Exchange Server running at WK *"~ 
the ePay Switch. 
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See Incremental Template Updating on page 19 for a complete description of 
the ESP System's use of Microsoft Exchange Server. 

ESP Template Authoring Workstation to the ESP Statement 
Origination Workstation 

This interface will consist entirely of new and visa's esp 

updated Templates. It can be either a LAN link or <m£££ 
* , sneakernet w - the exchange of floppy diskettes. Workstation 



m 



m 
o 



m 



Hi 
M 

o 
m 



Visa's ESP 
Template 
Authoring 
] Workstation 




CSP't Visa's Statement 

Home Banking Generation 
System Workstation 



ESP Statement Generation Workstation to the CSP's Home 
Banking System 

Administration Messages, Visa Format (ADV), 
Fully Rendered Statement PDF Files (STM), 
Optional Detail PDF Files, and Optional Generic 
Enclosure PDF Files are passed between the ESP 
Statement Generation Workstation, and the CSP's 
Home Banking System. 
Communication between the CSP and ESP will be in the form of a Local 
Area Network. The Windows NT software of the ESP Statement Generation 
Workstation can connect to most LANs in use today, including UNK 
TCP/IP, IBM SNA, Novell Netware, Windows NetBEUI, Appletalk, DECnet, 
etc. 

a. Transport Mechanism 

Data is passed in ASCII files stored in two subdirectories Ob-GSP 
and FromjCSP), or in subdirectories below them. Once copied, files 
are deleted by the recipient. 



i. Security 

The CSP will need a Windows NT account with password on 
the ESP workstation. This account will be limited to 
read/execute/delete access for TojCSP, and write/execute 
access for FromjCSP. 

il. Interface Control File 

Each subdirectory has an Interface Control File. 

This is a file recording each espy from and copy to performed 

by either party. It is archived by the ESP workstation. 

Row Contents: "FromTTo", "CSP w rESP w , Date-Time Stamp, 
Filename, Record Count, Hash Total (to be 
defined, by file type) 
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Filename: Control.txt 



b. 



To_CSP 



This will contain the following data files, all in comma-delimited 
ASCII format. 

I. Interface Control Total File 

ii. ADV - Administrative Messages, Visa Format 

See page 30 for a description. 

In addition, the following files will be placed in a Template 
subdirectory, named for the Template Number (Template ID without 
Version Number): 

iii. INF - Statement Index 

In comma-delimited ASCII format. See page 44 for a 
description. 

iv. The Statement Descriptor 

v. This ASCII text contains all data necessary to pay the 
Statement and to display it on i Non-Conforming 
Devices. 

See page 4240 for a definition of the Statement Descriptor^ 

•vh The Fully Rendered Statement PDF File 

One of these per Customer: for a large CSP there will be 
thousands of these for each Template. 

Since these are highly date specific, if Statement Batches 
Solution is used (see page 72), purging functions will have to 
be supplied by the CSP. 

Filenames for these PDF Files are provided in the Statement 
Index. 

See page 13 for a description. 

vii. Optional Details Index File 

In comma-delimited ASCII format. 

viii . Optional Details PDF Files 

ix. Optional Enclosure Index File 

In comma-delimited ASCII format 
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o 
o 
m 
w 



o 
m 



x. Optional Enclosure PDF Files 
FromjOSP 

This will contain the following data files, all in comma-delimited 
ASCII format. 

i. interface Control Total File 

ii. ADV - Administrative Messages, Visa Format 
See page 30 for a description. 
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ESP Test Mode - Template 
Certification 

When certifying a new Statement Template, a SSP will want to test the results before 
releasing it to production. 

1. Step 1: Enter Test Data 

Testing begins with entering test data into the data tables contained within 
^ the Template. This data is used to generate test Statements at the ESP 

=n Template Authoring Workstation. 

3 2. Step 2: Place New Template into Test Service 

01 

r% Once these meet the SSFs requirements, the Template is placed into Test 

g Service by uploading it to the ePay Switch via the Statement Template in 

pj] Test Service Req ADV. 

OS 

q 3. Step 3: SSP Opens a Test Customer Account with CSP 

Jtf The SSP opens a Customer account with a representative sample of CSPs. 

ut 

3 When this Test Customer requests ESP Service for a Statement, the 

U associated Customer Statement Delivery Request ADV is answered by a 

p Customer Statement Test Delivery Acknowledgment ADV. This sets the Test 

i~ E Account Flag in both the SSP and CSPCustomer Profile Tables (see page 

39), and generates a "Dummy" Statement Content Record transmission to 
the CSP, from the test data entered into the Template. If data has been 
entered for more than one month* then Statement Content Records will be 
transmitted for each month available. 

Statement Content Records arriving at the -ESP Statement Generation 
Workstation triggers the generation of a Fully Rendered Statement PDF File 
using the test data. 

Viewing these Statements via the CSP's Home Banking Software, in exactly 
the same way that the Customer will, will give the SSP complete confidence 
in their Template before placing it in production. 

4. Safeguards 

In order to safeguard against mishaps, Templates placed into Test Service 
(ref: Template Data 

Template Index Table on page 41) cannot generate Statements for non-test 
Customers (ref: CSP Customer Profile Table on page 40), nor can they be 
used to parse Statement Legacy Records from the SSP (ref: SSP Customer 
Profile Table on page 39). 



m 
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Future Considerations 

None of the following items will prevent the Pilot from going forward. Some of them will 
need to be addressed before General Release. 

1 . Downloading unchanging Statement elements to the 
Customer's PC is Inefficient 

Caching Statement elements on the Customer's PC is tricky because 
• many different configurations of PC's are possible 



• it is the property of the Customer, and requiring that files be 
v : stored there may be a political issue 

q In addition, new Adobe technology has greatly improved downloading of 

5 PDF Piles, as follows: 

y • all text and graphics are stored within the PDF File in Zipped 

^ format 

ru ■ 

m * repeating bitmaps are detected and included only once 

y • WWW bit-serving technology is used to display the PDF file as it 

is downloaded - the Customer does not have to wait until the 
Ul whole file is downloaded before viewing it 

H= , 2. Manipulation of Adobe Interactive Elements from within the 

O Template 

O 

yj Currently, manipulation of Adobe Interactive Elements within the The 

Interactive Page (see page 12) is restricted to FDF files generated by the 
FDF Writing Module (see page 16) within the Template. 

Direct manipulation of Adobe Interactive Elements on the Access Report 
would be a major benefit. This would allow, for example, a Web link to be 
placed over telephone numbers on a telephone bill! so that the Customer 
could find out who they had called. 

3. Too Many Fonts 

The performance of Windows workstations degrade when too many fonts are 
installed (over 600). 

Font management software may be needed for post-pilot implementation. 

4. Generation of Fully Rendered Statement PDF Files for Non- 
conforming Device Customers 

Generation of Fully Rendered State went PDF-FiUzs fox Nonconforming 
Device Customers is a waste of processing, since Non-conforming Devices 
cannot display Fully Rendered Statement PDF Files. 

Avoiding this is deferred to post-pilot implementation. 
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5. System Certification: Installation at New Sites, and System 
Upgrades 

Once the ESP System enters production, newly added SSP or CSP sites will 
have to be tested before they can join the system with any degree of safety. 
In addition, modifications to the ESP software, and installation of new 
versions of system software or hardware will have to be tested before they 
can join the system. 

This can be performed by a complete "test" system: a second ePay Switch, 
communications system and workstations. The Statement Origination 
Workstations will be designed to have a representative "test" Statement 
Content Record Stream to send upon command to a number of Statement 
Generation Workstations. 

This system needs to have only a small faction of the capacity of the 
Jjj production system, yet its value in certifying new sites j software and 

q hardware will be invaluable, especially in a high-reliability environment like 

tn esp. 

Q 

O 6. Determine OLE Servers to be made available to Statement 

m Originators 

fri 

^ OLE objects, such as graphs, drawings, etc., can be imbedded into Template 

^ reports. Use of such objects requires that the associated OLE Server (a 

it' program such as Microsoft Excel* CorelDRAW, etc.) be installed, in the 

u 1 correct version, at ALL ESP Statement Generation Workstations. 

M> This is a licensing and management issue, not a technical one. 

O 7. Statement Service Providers with Multiple Sites 



y3 
m 



Statement Service Providers with Multiple Sites will simply have a different 
SSP ID for each site. If a Statement Originator is delivering Statement 
Legacy Records to more than one site, they will require separate UBF Biller 
ID'S for each site. 

Since a Template can-be for only UBF Biller ID, this means that the 

appropriate Templates will have to be duplicated. 

It would be much more elegant if this was handled by the system. 
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Appendix A - What's New ? 

The purpose of this section is to highlight differences between the architecture described in 
Versions 1. 1 and 1.2 of this document 



1. Name Changes 



M 
Q 

y3 








Invoice 


Statement (may not reauire payment !!) 


Biller 


Statement Originator II 


ESP BSP Workstation 


ESP Statement Origination Workstation | 


Biller Service Provider 


Statement Service Provider 


BSP 


SSP II 


Customer Service Provider (CSP) 


Customer Financial Institution or its II 
Service Provider (CSP) 


Consumer 


Customer (may be a business) 


BSP Biller ID 


SSP Biller ID 


Biller Account Number 


CBAN 


Interactive Area 


Interactive Page 


Statement Index Record 


Statement Descriptor 


Billing Date 


Statement Cycle Date 1 



New Statement Structure 

The ESP System's market success will depend on satisfying both Customers 
and Statement Originators. Customers want to download only information of 
interest to them, and Originators do not want to annoy Customers with 
unwanted information. Accordingly, to encourage optional data and brevity 
in mandatory data, we have formalized the constituents of any statement, as 
shown below. 

a. Statement Constituents 
i. Interactive Page 

E.g. buttons to request optional documents, to access multi- 
media features, and to access Web-links 



ii. Mandatory Customer+Specific Pages 

E.g. bill summary 

iii. Mandatory Generic Enclosures 

E.g. regulatory enclosures 

iv. Optional Customer-Specific Pages 

E.g. bill detail 
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v. Optional Generic Enclosures 

E.g. promotions 

vl. Statement Descriptor Data 

E.g. summary data and pointers to PDF files. 

Statement Descriptor Data is the only one required. Note that 
current design provides explicitly for Optional Customer-Specific 
Pages, which, if present, will require generation of a second Access 
report. This second Access-generated PDF file would be created 
during the same OLE call to Access as the first 



iH b. Statement PDFs 



«| A Statement is presented to the Customer in the following parts: 

/. Fully Rendered Statement PDF File 



~~ This file contains the Interactive Page (if present) and any 

^ mandatory portions of the statement 



//. Optional Customer-Specific PDF File 

y3 At most one of these exists per Statement. E.g. Statement 

Detail. 



O 



H ///. Optional Generic Enclosure PDF Files 

q Any number of these exist for a Statement. E.g. promotions. 

% 3. CSP Portion of Interactive Page Deleted 

m Version 1.1 stated that each CSP would-be responsible for authoring an 

Interactive Page of fixed size to be merged with the SSFs portion of the 
Interactive Page, The CSFs portion ha* been required to have a Pay 
button and a "List of Statements 11 buttoft, and would likely have featured the 
CSFs logo as well. The CSP would have used Acrobat Exchange to create 
this portion of the page, and would have used a custom ESP plug-m 
(nicknamed the "Inverse Distiller") to save it in PostScnpt/PDFMark format 
CSPs would have becm required to register this PostScript fragment with the 
ePay Switch. Visa personnel would have verified its dimensions and 
functionality before marking it suitable for commercial use. 
For the current design, this requirement has been deleted bee ause we feel 
that the CSP*s interactive functionality (Pay ana List of Statement buttons) 
is better accomplished using the native format of the server. For Web- or 
Intranel-based servers, this format is HTML, whereas for Proprietary 
soaware, this format is the language (e,g. CT) used.to develop the software. 
In deleting this requirement, we put more control back into the hands of the 
CSP and also enable other simplifying changes to the generation process. 
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4. New Statement Authoring and Generation Procedures 

a. The Old Way 

The procedure for generating the Fully Rendered Statement PDF has 
been changed significantly. In Version 1.1, the Fully Rendered 
Statement PDF was generated by first creating CSP and SSP 
portions of the Interactive Page and saving them in 
PostScript/PDFMark format, using a custom plug-in to be installed 
with Acrobat Exchange at the ESP Template Authoring Workstation. 

These PostScript fragments were to be combined (by Adobe Distiller, 
which converts PostScript to P0F) with the Access-generated 
personalized statement that had previously been written to file in 
PostScript format The Interactive Page was to have been created in 
PDF format using Acrobat Exchange, converted to PostScript using 
the Inverse Distiller Custom Plug-In, and then merged with the 
Access output and converted back to PDF using Distiller. This 
circuitous procedure was needed to tightly stitch the Interactive Page 
to the Access page and to merge the CSP portion of the Interactive 
Page with the SSP's portion. 

b. The New Way 

By dropping the need to stitch the Interactive Page to the first page 
of the Access report, and by dropping the need for a CSP portion of 
the interactive page, we have simplified authoring and generation 
considerably. 

In the current design, the Interactive Page is created entirely by the 
Statement Originator as a forms-based Acrobat 3.0 document, and is 
saved as a Template resource. 

During Statement Generation, a FDF File may be created which is 
later used by Adobe Exchange to customize the Interactive Page. 

The Access report is written out directly in PDF format using 
Adobe/s PDFWriter device driver rather than being written first to 
PostScript and then later converted to PDF format by Adobe 
Distiller. 

Finally, the merge of the Interactive Page PDF, the Mandatory 
Customer-Specific PDF pages, and any Mandatory Generic Enclosure 
PDFs is accomplished using Acrobat Exchange, called as an OLE 
server to the main Visual Basic software. 

The current design avoids the need to develop and maintain (in C) 
the Inverse Distiller custom Acrobat plug-ih, the need to write 
custom code to accomplish the PostScript merge, the need to use 
Distiller, and the need to register and validate the CSP Interactive 
Area. 

5. Incremental Template Updating 

To minimize data flow, Templates will be updated rather than replaced - that 
is, only items that change will be transported through the system. 
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However, this capability may be deferred until after the Pilot. 
See Incremental Template Updating on page 19. 

6. Statement Content Record Transportation 

In both Version 1.1 and 1.2, Statement Content Records are to be transported 
as attachments to Microsoft Exchange (not to be confused with Adobe 
Exchange 1) mail messages. 

Version 1.1 was based on sending in each mail message a single attachment 
containing a comma-delimited representation of just those records (from one 
_ or more tables) needed to generate a single Statement This approach has 

£ the advantage that a corrupted transmission affects only one Statement, In 

the current design, each mail message will contain all the data needed to 
create a batch of Statement (e.g.: 500 or 5^000) in the form of separate 
«=j attachments, one for each required table; 

9 • By keeping data from different tables in separate attachments, 

i we avoid the processing time required for assembly and for 

y disassembly. 

• By grouping a batch of statements together in one mail message, 
}jj we improve the efficiency of SQL Server table updating. 

• To the extent that batches are kept small, we can minimize the 
impact of corrupted transmissions. 

The current design provides the ability to optimize the batch size by trading 
off the adverse impact of data corruption against the adverse impact of 
excessive processing to bundle and unbundle data. 

7. Distribution of Standard Statement Rendering Tool 

In response to expressions of interest from SSPs, the The Standard 
£H Statement Rendering fool (see page 49) will be made available to both CSPs 

and SSPs themselves, not just to Visa's workstations on their premises. 
SSPs and CSPs may wish to provide this tool to their Customer Service 
Departments. 

8. Switch Design 

To augment security and level telecommunications loading at the ePay 
Switch, we now plan to poll (call out to) all Workstations from the ePay 
Switch. 

In the event that CSPs or SSPs are unwilling to transfer data via incoming 
calls, we may institute call-back procedures wherein CSPs and SSPs call the 
ePay Switch whenever they receive any incoming call. 

Normally, the calls coming to CSPs and SSPs would be from the ePay Switch 
advising its desire to communicate. Authentication codes could be devised for 
the originating and the call-back calls that w?uM discourage hacking. 
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9. Administrative Messages 
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Generation Failure 

We have added an urgent message in the event of Statement 
generation failure. 

Statement Originator Splits and Mergers 

Statement Originator initiated account number changes, for 
whatever reason, will require a new Administrative Message from 
SSPs to CSPs. 




Dates are also needed for integrity in the event that Statement 
Originators re-assign account numbers to different customers using 
the same CSP, e.g. reassign telephone numbers. 

10. Mail Robots. 

In Version 1.1, an asymmetry in the mail delivery process arose because the 
CSP could only address Statement Originators and not their SSPs (to whom 
their mail must first be delivered). 

This was because the system had been designed such that CSPs do not know 
Statement Originator's SSPs. The consequence was that we needed a mail 
robot at the ePay Switch to log on as each Statement Originator and move 
that Statement Originator's incoming mail to the outbox of its SSP. 

For the current design, we are proposing to allow CSPs access to selected 
fields of the UBF which will allow them to address mail directly to a 
Statement Originator's SSPs. This eliminates the need for one mail robot 
process at the ePay Switch. 

11. Universal Blller File (UBF) 

Two new fields have been added to the UBF, one 16-byte field for an ID, and 
one 24-byte field intended for ESP flags. 

See UBF- Universal Bitter File on page 28 for a complete description. 

1 2. CSP Account Number 

CSPs will now be able to pass an identification field with each Customer 
Statement Delivery Request ADV that can be used to identify its Customers. 

This key will enable the Statement Generation Workstation to respond to 
queries for all Statements available for a given CSP Account Number. 
Note that use of this identification number is optional* and that the number 
if given need not correspond to the actual customer number used by the CSP 
to identify its Customer. 
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See CSP Customer Profile Table on page 40. 

1 3. Statement Download Log & CSP Pull Procedures 

A SSP may now request notification when one of their Statements is Pulled 
by the CSP and when it is Pushed to the Customer. 

See Statement Download Log on page 44. 

14. Summary Types 

Statements will be of a designated type, and Statement Descriptor (see page 
^_ 42) will vary accordingly. 

*j Types will include at the outset: invoices, statements, and advisories. 

Invoices are hills and are characterized by being payable. 

Jj 15. ESP Customer Activation 

O The option of having the Statement Origination Workstation respond 

Q positively or negatively to activation requests on behalf of the Statement 

K Originator has been dropped for lack of interest Instead, the Workstation 

lB will pass activation requests directly to the Statement Service Providers 

O system who will respond on the Statement Originator's behalf or pass it 
directly to the Statement Originator. 

m 

16. Payment Issues 

The capability to split payments among multiple accounts with the same 
^ payee will be deferred until after pilot . 

17. Multi-Site SSP Operations 

f* 1 SSPs who must generate statements for the same Statement Originator from 

multiple sites, each with its own SSP I®, will have to handle passing 
Templates and mail messages among these sites internally. We will 
continue view each Statement Originator as having a unique SSP endpoint. 



18. Security 

Although we may defer use of Exchange-based encryption and digital 
signatures on top of NT security during pilot to speed development, we 
continue to intend to implement this capability for commercial operations. 
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Appendix B- What it takes to be an 
ESP Statement Service Provider 



To set up operations as an ESP Statement Service Provider for the ESP Pilot will require 
the following: 

• Hosting of ESP hardware 

~Tz • Communication with the ESP hardware 

Us 

=g • Communication with Visa's ePay Switch 

• Modification to your current data processing system 

• Development of Statement Templates, in the form of Microsoft Access Reports 

A. Hosting of ESP Hardware 

Visa's ESP Statement Origination Workstation will be installed at your site. For purposes 
of the ESP Pilot, this will be a single Intel-based box running Windows NT Workstation. 
For production volumes* this may be upgraded to Windows NT Server, and several more 
Intel and non-Intel (e.g.: DEC Alpha) CPUs may be added. , 

During the ESP Pilot, this equipment will be developed, installed, and maintained by Visa. 
It will be operated by the SSF, and its reports will be monitored by the SSP. 

B. Communication with the ESP Hardware 

jjijj The SSFs System connects with the ESP Statement Origination Workstation via LAN. 

m The Windows NT software of the ESP Statement Origination Workstation can connect to 

most LANs in use today, including UNIX TCP/IP, IBM SNA, Novell Netware, Windows 
NetBEUI, Appletalk, DECnet, etc. 

Communication is via copying ASCII files over the LAN to and from Network Shares 
provided by the ESP Statement Origination Workstation. 

C. Communication with Visa's ePay Switch 

Communication from the ESP Statement Origination Workstation to Visa's ePay Switch will 
be required. The bandwidth necessary will depend completely upon the volume of 
Statements involved in the Pilot 

This will be supplied by the SSP to Visa's specifications. For purposes of the Pilot, a pair of 
telephone lines or a single IDSN line will be ample. 

D. Modification to your Current Data Processing 
System 

For a complete description of the SSPs system's requirements, please see page 49. 
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The main print stream will be split into two streams: one foT print and one for ESP, 
depending upon the Customer Profile Table. Some Customer's data will go to one or the 
other and some will go to both. 

The ESP stream will be modified into the format of Statement Legacy Recordsi Augmented 
(see page 41). 

The SSP will have to receive and process Administrative Messages (ADV - see page 28) and 
generate responses and return them to the &SP Statement Origination Workstation, See 
page 49 for a complete description of this process. 

E. Development of Statement Templates, in the form 

c of Microsoft Access Reports 

m 

^ 1. Statement Templates 

O TPL - The Statement Templates are described on page 15. 

3? One of these will be required for each different Statement type that will be 

jjj* processed by ESP. In addition, each month that a change is made to a 

J?! Statement, the Template must be updated. 

m 

pj 2. The level of Access expertise needed 

vD The level of Access expertise needed to generate a Template depends upon 

Iff the level of sophistication of the Statement. 

f Desktop-publishing staff should be proficient at developing simple Templates 

t with a few hour's training. Complex Templates will require the efforts of 

j^j both the desktop-publishing staff and an Access consultant 

*Q 
iff 

5 
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Appendix C- What it takes to be an 
ESP Customer Financial 
Institution/Service Provider 

To set up operations as an ESP Customer Financial Institution /Service Provider for the 
ESP Pilot will require the following: 

• Hosting of ESP hardware 

• Communication with the ESP hardware 

• Communication with Visa's ePay Switch 

O • Modification to your current data processing system 

S A- Hosting of ESP Hardware 

□ 

PJ Visa's ESP Statement Generation Workstation will be installed at your site. It is an Intel- 

flj based Windows NT system with a LAN connection to your Home Banking System, and a 

p communication link to Visa's ePay Switch. 

*Q For purposes of the ESP Pilot, this will be a single Intel-based box running Windows NT 

W Workstation. For production volumes, this may be upgraded to Windows NT Server, and 

s several more Intel and non-Intel (e g. : DEC Alpha) CPU's may be added. 

During the ESP Pilot, this equipment will be developed, installed, and maintained by Visa, 

y It will be operated by the CSP f and its reports will be monitored by the CSP. 

S B. Communication with the ESP Hardware 

BP A LAN connection with the ESP Statement Generation Workstation will be required. The 

Windows NT software of the ESP Statement Generation Workstation can connect to most 
LANs in use today, including UNIX TCPAP, IBM SNA, Novell Netware, Windows NetBEUI, 
Appletalk, DECnet, etc. 

C. Communication with Visa's ePay Switch 

Communication from the ESP Statement Generation Workstation to Visa's ePay Switch will 
be required. The bandwidth necessary will depend completely upon the volume of 
Statements involved in the Pilot. 

This will be supplied by the SSP to Visa's specifications. For purposes of the Pilot, a pair of 
telephone lines or a single IDSN line will be ample. 

D. Modification to your Current DP System 

Three major new functions must be added: ESP Sign-up, Statement and Optional Enclosure 
display, and Statement Payment. 

For a description of the data that must be stored and the processes that must be supported, 
see page 71. 
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Appendix D- A Sample Statement 
using Microsoft Access® Reports 

A. Introduction 

An sample Statement was generated using Microsoft Access® v7.0. ' The following elements 
are included: 

f= 1. A photocopy of the original Statement 

UJ 2. Adobe Acrobat (PDF) version of the Statement. 

Jj 3. Statement Augmented Records (SAR) 

0 4. The Statement Template, including Statement Stationary, parsing tables, and 
P reports 

2 6. Statement Content Records and Tables 

fy 6. Files, with their sizes in compressed and uncompressed form, as generated by 

ft] this example 

1 B. A Photocopy of the Original Statement. 

* ' Figure 11 - A Photocopy of the Original Statement 

5 C. Adobe Acrobat (PDF) version of the Statement. 

Jj Two Statements are generated, one for a Customer with Paid = True, and one, with Paid = 

False. 

m 



95000.952 



Appendix 1 Express Mail #EM300602468US 



Page 94 ESP System Architecture 

Figure 12 - A Statement with Paid = False 
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Figure 13 - A Statement with Paid = True 
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D. Statement Augmented Records {SAR) 

These SAR Records are in Fixed-Length format. They could also be in SQL-Table, Print- 
Image, or Comma-Delimited form. 

Note that Record type "OOOO" is the Statement Content Header. UBFBiller ID (BIN) = 
123456789012, and Template ID Number = T0000001. Holding is used to show separate 

fields. , , 
.........1. 2.-..;.... 3.-..;. ...4....;- ...5....;-.-. 6....;-... 7 

.8 ' 



000000000000 123456789012T0000001 

100400000000101222222306/06/96 
1004OOOl0000Su»ie Q Public 
100400020000123 Somewhere Ave, #999 
100400030000This ie the Place 
100400040000San Elsewhere, CA 99999 
10040005000006/21/960000432. 10BOO 678-B796444 555-12.12 
100400060000flan Elsewhere Showroom 
100400070000False 

11130001000106/01/9601000000-00 

1113O0O10002Rental- 9 items, 06/01/96 to 07/01/96 

11130002000106/01/9602100004.90 

1113 0002 00 02 BED FRAME- KINO, QUEEN 

11130003000106/01/96031000017.20 

111300030002BLUE DAMASK QUEEN MATTRESS 

11130004000106/01/96041000013 .40 

111300040002BLUE DAMASK QUEEN BGXSPRINQ 

11130005000106/01/9605200007.02 

1113 0005 00 02PROLIC CHAIR 

11130006000106/01/9606200009.60 

111300060002TARRAGANO NITE STAND 

11130007000106/01/96071000013.50 

111300070002BERLIN IVORY DINING TABLE 

11130008000106/01/9608100005.95 

1113 0008 0002LAMP- ALMOND 

11130009000106/01/96090000095.25 

111300090002Damaoe Protection00007 .0600095.25 

13130010000106/01/96010 

111300100002DiBtribution feeOOOOO . 0000040. 00 

100400000000239355758206/06/96 

100400010000John J Jones 

100400020000324 This Bt, #567 

100400030000Over There, CA 94402 

1100400040000 „ n **AA ccc 1on 

10040005000006/21/960000135. 25B00 67B-8796444 555-1212 

100400060000Foster City Showroom 

100400070000True 

I 11130001000106/01/9601000000.00 

1113000l0002Rental- . 9 items, 06/01/96 to 07/01/96 
i 1 1 130002000106/01/9602100004 .90 
]IIl300020002BED FRAME- KINO, QUEEN 

11130003000106/01/96031000017.20 

1113O0O30002BLUE DAMASK QUEEN MATTRESS 

11130004000106/01/96041000013 . 40 

1113O0O40002BLUE DAMASK QUEEN BOXSPRINO 

11130005000106/01/9605200007.02 
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111300050002FROIiiG CHAIR 

11130006000106/01/9606200009 .60 

111300060002TARRAGANO KITE STAND 

11130007000106/01/96071000013.50 

1113 00070 002BERLIN IVORY DINING TABLE 

11130006000106/01/9608100005.95 

1113 00080 002LAMP- ALMOND 

11130009000106/01/96090000095.25 

1113OOO90002Damage Protection00007 . 0600095 .25 

11130010000106/01/96010 

1113 00100 002Diotribut ion f eaOOOOO . 0000040 . 00 



Figure 14 - Statement Augmented Records (SAR) 
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E. The Statement Template 



The Statement Template consists of the following parts; 

• The Access Tables 

• The Access Reports 

• Statement "Stationary" Bitmap 

• SAR/Transport Mapping 

It also contains the Standard Class Module, as described in Appendix E - The Statement 
Template Access Class Module on page 103. 
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The Access Tables 

SAR Fixed Length Parsing Table 



a. 



:■ " ■ -: : 


5ft 




1 


;; - — r 


■ . 
171*1*1' 




1 




UBF Bitter ID 


text 


00000000000 
0 


13 


12 


2 




Template JD 


text 


00000000000 

o • 


25 


7 


3 




CBAN 


text 


10040000000 
0 


13 


10 


4 




Stetement_Cycle_Date 


date 


10040000000 
0 


23 


8 


5 




Customer_Name 


text 


10040001000 
0 


13 


0 


6 




Customer^ddress.l 


text 


10040002000 
0 


13 


0 


7 




Customer _Address_2 


text 


10040003000 
0 


13 


n 


8 




Customer_Address_3 


text 


10040004000 
0 


13 




9 




Due_Date 


date 


10040005000 
0 


13 




10 




Amount_Due 


currency 


100400.05000 
0 


21 


10 


11 




Questions_Phone 


text . 


10040005000 
0 


31 


13 


12 




Other__Phone 


text 


10040005000 
0 


44~ 


13 


13 




Location 


text 


10040006000 
0 


13 


0 


14 




Paid 


Boolean 


10040007000 
0 


13 


5 


1 15 


Items 


Item_Date 


date 


1113???7000 
1 


13 


8 


1 16 


Items 


Order 


integer 


1X13????000 
1 


21 


2 


17 


Items 


Quantity 


integer 


1113????000 
1 


23 


1 


18 


Items 


Monthly.Rate 


currency 


1113????000 
1 


24 


8 


19 


Items 


Cost 


currency 


1113,?7??000 
1 


32 


8 


B 20 


Items 


Description 


text 


1113????000 
1 2 


13 


0 



Figure 15 - SAR Fixed Length Parsing Table 











1 Font 


Century Schoolbook 


Schblk.ttf 


font-file 


Bitmap 


Statement Stationary 


T0000001.bmp 


bitmap of 

Statement Stationary \ 
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Figure 16 - Statement Resource Table 



FURNITURE RENTAL, INC. 
HOME & OFFICE 
P.O. BOX 100515 PASADENA, CA 91189-0515 



|H 



POR CHANGE OF ADDRESS MDICATE HEREfl AND SEE REVERSE ODE. 
HCAIE DETACH AND MAI. KHITO TOUR Mm&a # AAYWQ M PERM* KOJW BTATCMENt 



BILLING QUESTIONS? CALL 
FOR OTHER QUESTIONS, GALL: 
SEE BACK FOR IMPORTANT 



si 




Figure 17 - Statement 'Stationary" Bitmap 
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v. 


Tnnnnnm 




Field 


% t « j * * : % 

walue^sRecord 1 


l#alu$ * Eecord 2 


Account_Number 


1012222223 


2393557582 


Statement_Cycle_JDat 
e 


06/06/96 


06/06/96 


Customer_Name 


Suzie Q Public 


John J Jones 


Customer_Addres3_l 


123 Somewhere Ave, #999 


324 This St. #567 


Customer_Address_2 


This is the Place 


Over There. CA 94402 


Customer_Address_3 


San Elsewhere, CA 99999 




Due_Date 


06/21/96 


06/01/96 


Amount_Due 


$432.10 


$135.25 


Questions_Phone 


800 678-8796 


800 678-8796 


Otiier_Phone 


444 555-1212 


415 573-5120 


Location 


San Elsewhere Showroom 


Foster City Showroom 


Paid 


False 


True 



Figure 18 - Primary Data Records 



d. TOOOOOOIJtems 



Account 
NradMr' 


Stateme 


Date 




3 


* . 


Bate, 

v , T 3 


■ V:-.^w ■ • •■■ . 


1012222223 


06/06/96 


06/01/96 


1 


0 


Rental- Qiteins, 06/01/96 to 07/01/96 


$0.00 


$0.00 


1012222223 


06/06/96 3 


06/01/96 


2 


1 


BED FKAM&kKg, QUEEN 


$4.90 




1012222223 


06/06/96 


06/01/96 


3 


1 


BLUE DAMASK QUEEN MATTRESS 


$17.20 




1012222223 


06/06/96 


06/01/96 


4 


1 


BLUE DAMASK QUEEN BOXSPRING 


$13.40 




1012222223 


06/06/96 


r 06/01/96 


5 


2 


FROLIC CHAIR 


$7.02 




1012222223 


06/06/96 


06/01/96 


6 


2 


TARRAGANO NITE STAND 


$9.60 




1012222223 


06/06/96 


06/01/96 


7 


1 


BERLIN IVORY DINING TABLE 


$13.50 




1012222223 


06/06/96 


06/01/96 


8 


1 


LAMP- ALMOND 


$5.95 




1012222223 


06/06/96 


06/01/96 


9 


0 


Damage Protection 


$7.06 


$95.25 


1012222223 


06/06/96 


06/01/96 


10 


0 


Distribution fee 


$0.00 


$40.00 


2393557582 


06/06/96 


06/01/96 


1 


0 


Rental- 9 items, 06/01/96 to 07/01/96 


$0.00 


$0.00 


2393567582 


06/06/96 


06/01/96 


2 


1 


BED FRAME- KING, QUEEN 


$4.90 




2393557582 


06/06/96 


06/01/96 


3 


1 


BLUE DAMASK QUEEN MATTRESS . 


f $17.20 1 




2393557582 


06/06/96 


06/01/96 


4 


1 


BLUE DAMASK QUEEN BOXSPRING 


$13.40 




2393557682 


06/06/96 


06/01/96 


6 


2 


FROLIC CHAIR 


$7.02 




2393557582 


06/06/96 


06/01/96 


6 


2 


TARRAGANO NITE STAND 


$9.60 




2393557682 


06/06/96 


06V01/9T 1 


7 


1 


BERLIN IVORY DINING TABLE 


$13.50 




2393557582 


06/06/96 


06/01/96*" 


8 


1 


LAMP- ALMOND 


$5.95 




2393557582 


06/06/96 


06/01/96 


9 


0 


Damage Protection 


$7.06 


$95.25 


2393557582 


06/06/96 


06/01/96 


10 


0 


Distribution fee 


1 $0.00 


$40.00 



Figure 19 - 'Item" Data Records 



2. The Access Reports 

Two Access Reports are use: T0000001, and TOOOOOOIJtems. The second is included as a 
SubReport of the first, linked by Account Number and Statement Cycle Date. 

The Statement Stationary Bitmap is included as a Picture of the Report - i.e.: as a 
"Watermark". Converting this to a data-only report with the Stationary in a second PDF 
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file simply consists of deleting the Picture. This can be done from logic within the Report, 
triggered by, say, a global value in the Registry, set during system installation. 

The "Paid in Fuir notice is an OLE Link to a Microsoft WordArt v2.0 object, called 
Paid_in_Full. The On Format event for the detail lines says: 



Figure 20 - Code to control PcddJnJFuU 

In other words, we only see the WordArt object if Paid = True: 



F. Statement Content Records 



The Records 



Statement Content Records are transmitted in comma-delimited form. Records for all 
Statements for a single CSP and Statement Template are batched together into a single mail 
message. The message is addressed as to the CSP ID f from the SSP ID. 




Template T0000001 V0014 

T0000001VTOOO.txt has 2 records 

TD000001 VDGQO. Items.txt has 20 records 



Figure 21 - The SAR E-Mail 



Records for this Statement 



"1012222223 rt ,6/6/96 0:00:00,"Suzie Q Public","123 Somewhere Ave, #999 M 1 "This is the 
Place\ M San Elsewhere, CA 99999",6/21/96 0:00:00,$432.10,"800 678-8796 M ,"444 555- 
1212"."San Elsewhere Showroom",$0.00.0 , , . 



2393557582",6/6/96 0:00:00/'John J Jones ,, ,"324 mis St, #567","Over There, CA 
94402"„6/l/96 0:00:00,$ 135.25, M 800 678-8796","415 673-5120'7*Foster City 
Showroom",$Q,00.1 



Figure 22 - TOOOO001V000O.txt 

I "1012222223".6/6/96 0: 00:00.6/1/96 0:00:00.1.0 "Rental- 9 items. 06/01796 to 
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07/01/96" 1 $0.00,$0.00 

"1012222223".6/6/96 0:00:00,6/1/96 0:00:00,2, 1,"BED FRAME- KING, QUEEN",$4.90. 

"1012222223",6/6/96 0:00:00,6/1/96 0:00:00,3, 1 ( "BLUE DAMASK QUEEN 
MATTRESS",$17.20, 

"1012222223 , \6/6796 0:00:00,6/1/96 0:00:00,4, 1,"BLUE DAMASK QUEEN 
BOXSPRING".$13.40. 

"1012222223",6/6/96 0:00:00.6/1/96 0:Q0:00.5.2."FROLIC CHAIR".$7,02. 

,, 1012222223",6/6/96 0:00:00,6/1/96 0:00:00,6,2,"TARRAGANO NITE STAND M ,$9.60. 

,, 1012222223".6/6/96 0:00:00,6/1/96 0:00:00,7. l."BERLIN IVORY DINING TABLE".$13.50. 

"1012222223'\6/6/96 0:00:00.6/1/96 0:00:00,8, l.^LAMP- ALMOND".$5.95. 

"1012222223".6/6/96 0:00:00.6/1/96 0:00:00,9,0, w DamageProtection".$7. 06.^95,25 

"1012222223".6/6/96 0:00:00.6/1/96 0:00:00. 10.0, ,, Di8tributionfee ,, .$0.00.$40.00 

"2393557582",6/6/96 0:00:00,6/1/96 0:00:00,l,0, M Rental- 9 items, 06/01/96 to 
07/01/96".$0.00.$0.00 

"2393557582",6/6/96 0:00:00.6/1/96 0:00:00,2. l."BED FRAME- KING, QUEEN",$4,90. 

"2393557582",6/6/96 0:00:00,6/1/96 0:00:00,3, 1,"BLUE DAMASK QUEEN 
MATTRESS".$17.20. _ 

n 2393557582",6/6/96 0:00:00,6/1/96 0:00:00,4, l/'BLUE DAMASK QUEEN 
BOXSPRING".$13.40. • 

"2393557582".6/6796 0:00:00.6/V96 0:00:00,5.2."FROLIG CHAIR M .$7.02. ■ 

"2393557582 H .6/6/96 0:00:00.6/1/96 0:00:00.6.2. ,, TARRAGANO NITE STAND",$9,60. 

"2393557582".6/6/96 0:00:00.6/1/96 0:00:00.7. l.^BERLIN IVORY DINING TABLE".$ 13.50. 

"2393557582".6/6796 0:00:00.6/1/96 0:00:00.8. l."LAMP- ALMOND".$5.95. 

"2393557582".6/6/96 0:00:00.6/1/96 0:00:00.9.0.' , Damage Prbtection".$7.06.$95.25 

"2393557582".6/6/96 0:00:00,6/1/96 0:00:00, 10.0,"Distribution fee".$0.00,$40.00 



Figure 23 - T0000001VOOOO_Items.txt 

G. File Sizes. 





i 3k* 0>yfe*> 




T0000001.bmp 


671k 


- "Stationary" bitmap (not used) 


TOOOOOOLcdr 


35 k 


- "Stationary* bitmap - CorelDRAW! 


TOOOOOOLmdb 


254k 


- Access Database with reports & bitmap 


mdb.zip 


85 k 


- contains T0000001.MDB 


T0000001.pdf 


63 k 


- "Complete" PDF 


PDF.zip 


53 k 


- contains T0000001.pdf- already compressed 



Figure 24 - File Sizes for the "Brook" Statement 
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Appendix E - The Statement Template 
Access Class Module 

A Microsoft Access "Class Module' allows Access to act as an OLE Automation Server It is 

m£^TT!f ™ mpl0te 1)6 pr0CeSSed by **« ESP Statement Generation 
Workstation, the following must be defined within the public Class Module: 



Properties 


GBAN 

Statement Cycle J)ate 


Used to select records from Statement Content { 
Tables. || 




Show_Stationary 
Data Source 


ditto | 
True or False* Hides or shows Statement 
"Stationary", in the form of a "Picture" on the 
main Repoirt or SubReport. 


I Methods 


Connect JString 


^est w or*Prod tt 

If DataJSource = "Prod" then use 

Connect String to attach to ODBC Database. 




Generate Report 


1/ Set output to file <CBAN>.PDF 

(e.g.: "(415)372-1492.PDF? Note that this 
assumes that the CBAN does not contain 
any characters that Microsoft Windows NT 
v4.0 considers illegal in filenames. This is 
subject to conformation). 

21 Set the Report Filters to select only this 
CBAN. 

3/ Generate the Report 



Figure 25 - Properties and Methods Common to ALL Statement Templates 
Other Properties and Methods will be added as needed. 



95000.952 



Appendix 1 Express Mail #EM300602468US 



Page 104 ESP System Architecture 



m 

H 

o 

O 
O 

ru 
m 

Q 



Appendix F - Anatomy of the Access 
Examples 

Two example Statements are presented: the Brook Statement of Appendix Dand a Pacific 
Bell Statement. 



A. The Brook Invoice Template 




1. 



The Tables 

IAR_Fixed_Length_Parsing Table 



a. 



BtfecUv 


Name / 






^$$n -■' 


Field 


Field 
Lert. 


06706/96 




UBFBilUrlD 


text 


000000000000 


13 


12 


06/06/96 




Template ID 


text 


000000000000 


25 


7 


06/06/96 




Biller Account Number 


text 


100400000000 


13 


10 


06706/96 




InvoiceJate 


date 


100400000000 


23 


8 


06/06/96 




Customer Name 


text 


100400010000 


13 


0 


06706/96 




Customer Address 1 


text 


100400020000 


13 


0 


06/06/96 




Customer Address_2 


text 


100400030000 


13 


0 


06706796 




Customer Address 3 


text 


100400040000 


13 


0 


06706796 




Due Date 


date 


100400050000 


13 


8 


06706/96 




Amount Due 


currency 


100400050000 


21 


10 


06706/96 




Questions Phone 


text 


100400050000 


31 


13 


06/06/96 




Other Phone 


text 


100400050000 


44 


13 


06706796 




Location 


text 


100400060000 


13 


0 


06706/96 




Paid 


boolean 


100400070000 


13 


5 


06/06/96 


Item 


Item Date 


date 


11137W0001 


13 


8 


06/06/96 


Item 


Order 


integer 


1113????0001 


21 


2 


06/06/96 


Item 


Quantity 


integer 


1113????0001 


23 


•1 


06/06/96 


Item 


Monthly Rate 


currency 


1113????0001 


24 


8 


06/06/96 


Item 


Cost 


currency 


1113????0001 


32 


8 


06706/96 


Item 


Description 


text 


1113????0002 


13 


0 



^0 
=J3 
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b. lnvoice_Resource_Table 



Effective . 
Bate 


|)ftvoic& 


1 :". 1 

lavoiee ' 
Source 


PileNatne ■ 

illiifitltil 

uippiil 


Invoice 
Be$ource 

• < 


06/06/96 


Font 


Century 
Schoolbook 


Schlbk.zip 


Binary Object 


06/06/96 


Bitmap 


Invoice 
Stationary 


cdr.zip 


Binary Object 



c. T0000001-V1 



Acd# 




On 




CttiifcK 
rout" 


mt • 


: 


Aaaou; 

£ ' 


land 


: Other 


Location 

• 


i iPrev 
Sal 






Pi 

mem 

■: 


r 

Na 

'ate 


tr 


A<idre 
mt' . 


Adore 

J*' ■■ 

". ' , 

% : V-.-q*' 


- 

. 


Due 


Phone 

■ 




■ * • 

: . . . . - . 


■ 




10122 


06/06/96 


Sue 


123 


This 


San 


06/21/ 


$432. 


800 


444 


San 


$0.00 


0 


22223 




ie 


Some 


is the 


Elsew 


96 


10 


678- 


555- 


Elsewhe 










Q 


where 


Place 


here, 






8796 


1212 


re 










Pu 


Ave, 




CA 










Showroo 










blic 


#999 




99999 










m 






23936 


06/06/96 


Joh 


324 


Over 




06/01/ 


$135. 


800 


415 


Foster 


$0.00 


-1 


67582 




nJ 
Jon 
es 


This 

St, 

#667 


There 

,CA 

94402 




96 


26 


678- 
8796 


673- 
5120 


City 

Showroo 
m 







d. T0000001 Items-v1 



Account - 
Number 


Invoice 


Item Date 

> 


Order 




. • 


Monthly 
Rat* 




1012222223 


06/06/96 


06/01/96 


1 


0 


: Rental- 9 items, 
06/01/96 to 07/01/96 


$0.00 


$0.00 


1012222223 


06/06/96 


06/01/96 


2 


1 


BED FRAME- KING, 
QUEEN 


$4.90 




1012222223 


06/06/96 


06/01/96 


3 


1 


BLUE DAMASK QUEEN 
MATTRESS 


$17.20 




1012222223 


06/06/96 


06/01/96 


4 


1 - 


BLUE DAMASK QUEEN 
BOXSPRING 


$13.40 




1012222223 


06/06/96 


06/01/96 


5 


2 


FROLIC CHAIR 


$7.02 




1012222223 


06/06/96 


06/01/96 


6 


2 


TARRAGANQ NITE 
STAND 


$9.60 




1012222223 


06/06/96 


06/01/96 


7 


1 


BERLIN IVORY DINING 
TABLE 


$13.50 




1012222223 


06/06/96 


06/01/96 


8 


1 


LAMP*- ALMOND 


$5.95 




1012222223 


06/06/96 


06/01/96 


9 


0 


Damage Protection 


$7.06 


$95.25 


1012222223 


06/06/96 


06/01/96 


10 


0 


Distribution fee 


$0.00 


$40.00 


2393557582 


06/06/96 


06/01/96 


1 


0 


Rental- 9 items, 
06/0y96 to 07/01/96 


$0.00 


$0.00 


2393567582 


06/06/96 


06/01/96 


2 


1 


BED FRAME- KING, 
QUEEJN 


$4.90 




2393557582 


06/06/96 


06/01/96 


3 


1 


BLUE DAMASK QUEEN 
MATTRESS 


$17.20 




2393557582 


06/06/96 


06/01/96 


4 


1 


BLUE DAMASK QUEEN 
BOXSPRING 


$13.40 





95000.952 



Appendix 1 Express Mail #EM300602468US 



Page 106 



ESP System Architecture 



2393557582 


06/06/96 


06/01/96 


5 


2 


FROLIC CHAIR 


$7.02 




2393557582 


06/06/96 


06/01/96 


6 


2 


TARRAGANO NITE 
STAND 


$9.60 




2393557582 


06/06/96 


06/01/96 


7 


1 


BERLIN IVORY DINING 
TABLE 


$13.60 




2393557682 


06/06/96 


06/01/96 


8 


1 


LAMP- ALMOND 


$5.95 




2393557582 


06/06/96 


06/01/96 


9 


0 


Damage Protection 


$7.06 


$95.26 


2393557582 


06/06/96 


06/01/96 


10 


0 




$0.00 


$40.00 



2. The Reports 
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T0000001-V1 




Private Sub Detail_Format(Cancel As Integer, FormatCount As Integer) 

Me!PaidJn^FuU.Visible = (MelPaid) 
End Sub 



95000;952 



Appendix 1 Express Mail #EM30G602468US 



Page 110 



ESP System Architecture 



m 

H 
o 
m 
o 
o 
m 
m 



□ 
en 



343- 
8441 
764 N 
7159 



416 
343- 
8441 
764 N 
7159 



415 
343- 
8441 
764 N 
7159 



415 
343- 
8441 
764 N 
7 169 



06/02/96 



06/02/96 



I Taxes 



Taxes 



06/02/96 



415 
343- 
8441 
764 N 
7159 



415 
343- 
8441 
764 N 
7159 



415 
343- 
8441 
764 N 
7169 



415 
343- 
8441 
764 N 
7 159 



415 
343- 
8441 



06/02/96 



06/02/96 



Taxes 



10 



Taxes 



Surcharg 
e 



State 
Regulator 

I y Fee 



CA Relay 
Service 
and 
Cotnunica 
tions 
Devices 
Fund 



Tax: Fed; 
.45 911; 
.08 

Local: 



11 



06/02/96 



06/02/96 



06/02/96 



Instal 
lment 
Billin 

e 



12 



Instal 
lment 
Billin 
g 



13 



Instal 
lment 
Billin 



14 



Instal 
lment 



Service 
Connectio 
n 

Residence 
Service 
Flat Rate 



Total - 
Charges 
Applied to 
your 

Installme 
nt Plan 



Your 
Charges 
Will Be 
Billed in 
3 

Installme 
nts 



Installati 
on 

Payment 



$0.05 0 



$0.17 0 



$0.53 0 



$4.99 -1 



$0.00 



$0.00 



$34.75 0 



i;oo 



$0.00 



$34.75 -1 



$0,00 



$0.00 



$0.00 0 



$0.00 



$11.5 
8 



$11.58 0 
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a. TQ000002-V1 



Hllil MMI 



SOT 



Residence Sirtw flrt Rate*""} 


Recount Numbed 


Statement Date 


Accounl_Number ~j 


batementjJste 




Customerjyteme . 




Unbound 




Unbound ' 


Unbound 


jUnbound 

■ 



§Tv/o«tded form saves paper!] 



jPACIPICHBELL 



&ccourt_Nuirt)er "~ 



Statement Date 



Statem8nt_Date 



pPage [Pagei) 



fQuesttons ■bout Pacific 




If yeur payment has 



BaO-Cugtonwrservtee: 




BOO-aiCMBOLi 



hafi *r A eervfCes that make rt m0re convenient to pay 
^ur telephone Wl. Automatic Payment Service orPay-By-Phone 
IWfth Automahc Payment Serevica your bill is paid automatically ' 

phone call. Beat of all both services are free, For more 
information or to apply for these services call 1-800^94-9794. 



note page separator here ... 
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Pa <fflc BelTMonthly Chafflfts | 




Private Sub Detail.Poxxoat (Cancel As Integer, FormatCount As Integer, 



End Sub 



lblTotal_Due. Caption = Space(50, ^ 

& "A late charge may be applied on ■ 

& Format (Mel Late_Date f -mmm d") ~ 

= lblTotal_Due. Caption _ 

•v^/Syfi Pa y menC has not been received. - 
■ ?k however ' must still be paid before 

'(See* E£JF* t0 ^ ° ther 



lblTotal_Due . Caption 



& 
& 

& 

& 



Q 

o 

01 
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InSer, SUb ^""—-^t (Cancel As integer. FormatCount 



Integer) 

Dim sAddress (1 To 4) 
i ********** 



As 



As String 



sAddress 1) = MeICustoiner_Address 1 

™" ess 2> = MeJCustomer^ddress~2 

sAddress(3J = M e iCu S tomer__Address~3 

sAddress (4) = MeiCustoiner_Address~4 

If Len { sAddress (1) ) = o Then 
sAddress (1) = sAddress (2) 
sAddress (2) = sAddress (3) 
sAddress(3) = sAddress (4) 
sAddress (4) = 

End If 

If Len (sAddress (2)) = 0 Then 
SAddress (2) = sAddress (3) 
SAddressO) = sAddress (4) 
sAddress (4) = 

End If 

If Len (sAddress (3)) = o Then 
sAddress (3) 8 sAddress (4) 
sAddress (4) =. ■ ■- 

End If 

MeitxtAddress_l = sAddress (l) 
MeltxtAddress_2 = sAddress (2) 
MeltxtAddress_3 = sAddressO) 
MeltxtAddress_4 = sAddress(4) 



End Sub 



b. T000P002_Current_Charges-v1 




jfota that all of these fields have .Top = 0. Q4», and that they are spread out for clarity on ly. 
Pacific Ben 



Page 2 



$27,82 
$27.82 



Private Sub DetaiI_ror*at (Cancel As Integer, FormatCount As Integer) 

'Line_Before . . . 

If Me 1 Iten\_Number = 1 Then 

Line__Bef ore. Visible = False 
Description. FontWeight = 400 'normal 
lblPage_Number.FontWeight = 400 
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Amount. FontWeight = 400 

Else 

Line_Bef ore. Visible = True 
If MelIs_Total Then 

Line_Before.BorderWidth = 3 
Description. FontWeight = 700 'bold 
iDiPage_Number. FontWeight = 700 
Amount. FontWeight = 700 

Else 

Line__Before.BorderWidth = 1 

lt>lPage_Number. FontWeight = 400 
Amount. Font Weight =400 
End if 

End if 

'lblPage_Number ... 

If MelPage_Number = 0 Then 

Else lblPage - Nuinber - vls ible = False 

lblPage_Number. Visible = True 
End I f blPage - Number - Caption = -Page 



& MeJPagejtfumber 



End sub 



T0000002JnstallmenLBilling-v1 




Dim miLine_Count 



As Integer 



Private Sub Detail.Forn.at (Cancel As lnteger , FormatCount ^ Integer) 
miLine_Count = miLine_Count + 1 

'Linejefore ... 

If MelIs_Total Then 

Line_Before.BorderWidth = 3 
Description. FontWeight = 700 'bold 
Amount. FontWeight =700 

Else 

Line_Before.BorderWidth = 1 
Description. FontWeight = 400 'normal ' 
Amount. FontWeight =400 
End If 
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'Line_Number ... 

If Quantity <= o Then 

Description. Left = l * 1440 
Quantity. Visible = False 

Else 

Description. Left = 1.75 * 1440 
Quantity. visible = True 

End if 



m 
v 

H 
O 

o 



m 

£ 

5 



Select Case True 

case SK&:,JiS&5r: t sr pti «» > °> * ^_ cowt .. l 

Line_Bef ore. Width =0.5 
Line_Bef ore. Left = 1 * 1440 
Line__Bef ore. Width = 6 * 1440 

Case Quantity = -l 

Line_Bef ore. Visible = False 

Case Else 

Line_Bef ore. Visible = True 

Line_Bef ore. Left = 0 

Line_Bef ore. Width = 5.25 * 1440 

Line_Bef ore. Left = 1.75 * 1440 
End Select 



End Sub 



TOOOQ002_MonthlyJ3harges_Short-v1 




Note that all of these fields have .Top=0.04», and that they are spread out for clarity only. 
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Description 



Access tor Intensate Calling 
3.50 Per Month 



Qty Probated OneTIm 



11. 



Residence Service Flat Rate 
11 .25 Per Month 



Dim miLine_count 



As Integer 



Ai 




Private Sub Detail_ Form at (Cancel As Integer, FormatCount As Integer, 

miLine_Count = miLine_Count + l 

'Line^Before . . . 

If Meiis_Total Then 

Line_Before.BorderWidth = 3 
Description.FontWeight = 700 'bold 
Amount . FbntWeight =700 

Else 

Line_Before.BorderWidth = 1 
Description.FontWeight = 400 'normal 
Amount. FontWeiaht = 400 
End If 
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' Line_Number 

If Line_Number = 0 Then , * ^ T 

Description. Left = 0.5 * 1440 Len (Description) > o 

Line^Number. Visible = False 

Else 

Description. Left = 1 * 1440 
Line_Number. Visible = True 

End If 



m 
v 

1 

01 

o 



If (Line_Number = 0 And Len (Description) > 0) Or miLine_Count = l 

Line_Bef ore. Width = 0.5 Then 
Line_Bef ore. Left = 0.5 * 1440 
Line_Bef ore. Width = 6.5 * 1440 

Else 

Line_Bef ore. Left =0 
Line_Bef ore. Width = 6.15 * 1440 
LineJBef ore. Left = 0.85 * 1440 
End If 



m 
m 
o 

m 



'Quantity... 

If IsNull (Quantity) Then 

Quantity. Visible = False 

Else 

Quantity. Visible = (Quantity > 0) 
End if J '• 

' lblAmount_CR 

lblAmount_CR. Visible = (Amount < 0) 

End Sub 

Private Sub GroupHeaderO__Format (Cancel As Integer, 

Select Case Me J Type FormatCount As Integer) 

Case -Basic-: lblQuantity .Visible = True 

lblPro_Rated. Visible = False 

Probated. Visible = False 

lblOne_Time. Visible = False 

One_Time. Visible = False 



Case -Taxes- : 



Case Else: 



End Select 



lblQuantity. Visible = False 
lblPro_Rated. Visible = False 
Pro_Rated. Visible = False 
lblOne_Time. Visible = False 
One_Time. Visible = False 

lblQuantity .Visible = True 
lblPro_Rated. Visible = True 
Pro_Rated. Visible = True 
lblOne__Time. Visible = True 
One_Time. Visible = True 



miLine_Count = 0 
End Sub 
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e. T0000002_Monthly_Charges_TaII-v1 




• Basic Service 



Description 



1. Residence Service Fht Rate 



fcfcntrty Service Jun 2, 1936 tnojAJI, 1936 



Qty 



m 
m 



m 



Description 



9. Installation Payment Due 1 to 3 



Description 



Sendee Correction 
Residence Service Fid Rate 



Total Charges Applied to your Installment Plan 



Yotr Charges Will Be BItedh 3 Instalments 
' Taxes and Surcharges 

Description 



Qty Pro-Rated One-Tine 



Ai 



1158 



Qty Probated One-Tiro 



Ai 



2. Changes tor Network Access tor Interstate Cdlng, Imposed by Federal 
Com muni call ens Ctm mission 



3. Cafltomta High Cod Fund Surcharge 



4; Universal Ufeine Telephone Service Surcharge 



Rate Surcharge 



B. State Regulatory Fee 



7. CARdaySer^ceandCOTurtcgUonsDevioesFund 



8 ; Tex Fed .45 911: j08 Local: 



Dim miLine_Count 



As integer 



* *************************************************** 

Private Sub Detail_Format (Cancel As Integer, FormatCount As Integer) 

miLine_Count = miLine_Count + 1 

1 Line_Bef ore ... 

If MellsJTotal Then 

Line_Befdre.BorderWidth = 3 
Description. FontWeight =700 'bold 
Amount. FontWeight =700 

Else 

Line__Before.BorderWidth = 1 
Description. FontWeight = 400 'normal 
Amount. FontWeight = 400 
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End If 



' Line__Number ... 

If Line_Number = 0 Then . * * r 

Description. Left = 0.5 * i 440 (Description) > o 



Line_Number. Visible = False 
Else 

Description.Left = l * 1440 
Line_Number. Visible = True 

End If 



jjj If (LinOtanber = 0 And Len (Description) > 0) Or miLine_Count = 1 
Line_Bef ore. Width = 0.5 Then 

r ; Line_Bef ore. Left = 0,5 * 1440 

^ Line_Bef ore. Width = 6.5 * 1440 

ffl Else 

O Line_Be fore. Left = 0 

p LineJBef ore. Width =6.15 * 1440 

fll LineJBef ore. Left = 0.85 * 1440 

« End If , 

O 

J3 'Quantity... 

Ul If IsNull (Quantity) Then 

3 Quantity. Visible = False 

'J. Else 

Z Quantity. Visible = (Quantity > 0) 

^ End If 



' lblAmount_CR 

lblAmount_CR. Visible = (Amount < 0) 

End Sub 

Private Sub GroupHeaderO^Ponnat (cancel As Integer, FormatCount As 

Integer) 

Select Case Me! Type 

Case -Basic-: lblService. Caption = "* Basic Service- 

lblQuantity. Visible = True 
lblPro_Rated. Visible a False 
Pro^Rated. Visible = False 
lblOne_Time. Visible = False 
One_Time. Visible = False 

Case -Taxes-: lblService .Caption = •* Taxes and Surcharges" 

lblQuantity. Visible = False 
lblPro.Rated. Visible = False 
Pro_Rated. Visible = False 
lblOne_Time. Visible = False 
One_Time. Visible = False 

Case Else: lblService. Capti on = — — 

lblQuantity. Visible = True 
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End Select 
raiLine_Count = o 
End Sub 



lblPro_Rated. Visible = True 
Pro_Rated. Visible = True 
lblOne_Time . Visible = True 
One_Time. Visible = True 



f. T0000002 J»revlous_Charges-v1 



he* 

m 



o 
m 
o 
o 
ry 
m 

Q 

m 



u 
^0 




Amount of last bill 


$0130 1 


Payments) | 




$0.00 



Private Sub Detail.Format (Cancel As Integer, FormatCount As Integer) 

If Me J Itenu.Number = 1 Then 

Line_Bef ore. Visible = False 
Description.FontWeight = 400 'normal 
Amount. FontWeight =400 

Else 

Line_Bef ore. Visible = True 
If MelIs_Total Then 

Line_Before.BorderWidth =3 

Description.FontWeight = 700 'bold 

Amount. Font Weight =700 

Else 

Line_Before.BorderWidth = 1 
Description.FontWeight = 400 'normal 
Amount .FontWeight = 400 
End If 
End If 



End Sub 
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HI 



□ 



g. T0000002_Services-v1 




■We Are Not Holding a Deposft on Your Account 

•Service Is Billed In Advance torn the 2nd of Each Month 

• E asy Access established wth MCI 
on 1 Bne(s) effective Jun 1 , 1996. 
To verify your canter, call 1^700-5554141 . 

- Activity on 415 343-1234 
■Order 4541 7777 

■Installment Billing Effective on Jun 1 , 1996 
■Service Established torn Jun 1 , 1998 thru Jun 1 , 1996 



Private sub Detail_Ponnat (Cancel As Integer, FormatCount As Integer) 
Select Case Is_Total 

Case True: Description. FontWeight = 700 'bold 

Case Else: Description. FontWeight = 400 'normal 

End Select 



End sub 



m 
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Appendix G ■ ESP System Data Flow 
Projections 

ESp E «vl™ re ^f heet ""I 161 WM devel °P^ to quantify estimates of data flow through the 
™7 v.' J y ?fl en * n ™ are of P^ular interest: one corresponding to Sof 
program scheduled for early 1997 and one corresponding to a maLe sy^m The pilot 

wl „!IS ♦ ^ uw P }°J^ eilt ^ mature system results are of special interest because 
we need to be able to verify &at the system architecture is easily scaleable. 

A. Assumptions 

£a? d ^m^ nereS ^ tS L 8 Syttemlnput Volumes andFigure 

£L wWuX^^n ° Wi Fie T 2626 C ° ntainS ass ™P*<«K that varied between 
cases while Figure 2727 shows assumption s common to the two « .«.«, 



Participant Counts 



Statement Originators 
Originators, This SSP 



CSPb 
Customers 



Customers. This CSP 



Template Data 



Templates Per Originator 



Monthly Template Update Size (kb) 
Tries per Update Success 



Global Template Fraction 



Statement Data 



Statements Per Originator-Month 



Statement Content Size (kb) 



Statement Component Counts 

Mandatory Generic Enclosures 



Optional Generic Enclosures 



| Stateme nt Optional Component Take Rates 
Personalized Originator Buy-In 



Personalized Customer Take Rate 
Generic Take Rate 



2.000 
1,000 



1.0 



506 



10.000 
2,500 
100 



2,500.000 
250.000 



300 



100% 



500 



2.5 



10% 



75% 



25% 



40% 



2,000 
,10 



1.5 
10 



25% 
40% [ 



10% 8 



Figure 26 - System Input Volumes 
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Both Systems 


Statement Component Sizes (kb) 




BSP Interactive Page 


40 


Mandatory Personalized (Access-baaed) 


40 


Optional Personalized (Access-based) 


60 


Mandatory Generic 


15 


Optional Generic 


60 


Communications Efficiencies 




OrfetoSSP 


85% 


SSPtoSOrierWS 


98% 


SOrteWStoeSwitch 


90% 


eSwitch toSGen WS 


90% 


SGenWStoCSP 


98% 


CSP to Customer 


85% II 



Figure 27 - Common Parameters 



B. Results 



Following are two sets of results* seven pages each set, for the Kansas City Pilot and a 
Mature System. Each set begins with a network diagram summarizing data flow results, 
then a table of input data for the case, and finally five pages of detailed output. The 
calculations are described in the section following. . 
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ePav System Flow S/w«mVi. 

Kansas City Pilot g w /«fnn o 
Statement Side Workstation M^ ly p, min 



OUTPUT 



O 



ru 



=d3 



Aggregate Incoming/Share 
From SSPs 
Template Updates 
Content Reeds 
Admin Msgs 

Total: - 

Aggregate Outgoing 

To eSwitch: 
Template Updates 
Content Reeds 
Admin Msgs 

Total: 



Count 



Mb 



16 
2,000 



8.0 
5.0 



16 
2,000 



13.0 



8.0 
5.0 



13.0 



Lines Required (100% Utilization) 
From SSP: 

Eff: 98% 

To eSwfah* 
Eff: 90% 



1,544 . 


128 


57.6 


0.0 


0.0 


0.0 


1,544 


128 


57,6 


0.0 


0.0 


0.0 



Name 


kbits/sec 


$/Mo 


100Mbs 


100,000 


LAN 


T3 


44,184 


70,000 


16Mbs 


16,000 


LAN 


10Mbs 


10,000 


LAN 


T1 


1,544 


2,000 - 


ISDN 


128 


100 


56K 


58 


150 


28.8 


28.8 


30 


14.4 


14.4 


30 


9.6 


9.6 


30 | 



eSwitch Monthly Flows 



=0 
6 

m 
o 

Q 

m 



1 ^ 

I =i5 



01 



Aggregate Incoming 
Template Updates 
Content Reeds 
Admin Msgs 


Count 

80 
10 ( 000 


Mb 

40 
25 




Total: 




' 65 




Aggregate to Storage 
Template Updates 
Content Reeds 
Admin Msgs 


20 
10,000 


10 




Total: 




35 




Aggregate Outgoing 
Template Updates 
Content Reeds 
Admin Msgs 


40 
10,000 


20 
25 




Total: 




45 




Lines Required (100% Utilization) 

FromSSWS: l?a 
Eff: .90% o.O 


57.6 
0.0 


28.8 
0.0 


To SGWS: 

Eff: 90% 


128 
0.0 


57.6 . 
0.0 


28.8 
0.0 



i 



I 

I 

! 



i 
I 

I 
t 

i 



Statement Generation Wnrittrtatlon: Monthly nm** 



w 
m 
o 



m 



Aggregate Incoming Count 

' From=eSwftG^ 

Template; Updates ... 20. 

Content -Reeds ' 5 1 qqq 

Admin Msgs 
FromCSP 
Admin Msgs 

Total: 



Mb 



13 



23 



jjj PDFs Per 1000 Statements 

BSP Interactive i t 00O 40 

Acc Req'd, C-Spec 1,000 40 

Acc Optional, C-Spe 100 6 



O 

m 

Req'd, Generic t 0 

Optional, Generic 5 



_0_ 

Total: 86 



Aggregate Outgoing / Share 
ToCSP 

Initial PDFs 5,000 475 

C-Spec Opt PDFs 500 ■ 20 

Generic Opt PDFs 100 9 

Admin Msgs 
To eSwttch: 
Admin. Msgs 



Total: 504 
Lines Required (100% Utilization) 



From eSwitch 


1,544 


128 


57.6 


Eff: 90% 


0.0 


0.0 


0.0 


To CSP 


1,544 


128 


57.6 


Eff: 98% 


0;0 


0.0 


0.0 



CSP Home Banking Software Monthly Flows 



UJ 



m 



u 
■ ry 

00 



Aggregate Incoming / Share 



From Stmt Gen WS 
Initial PDFs 
C-Spec Opt PDFs 
Generic Opt PDFs 
Admin Msgs 

Total: 



Count 



5,000 
500 
100 



Aggregate Outgoing / Share 

To Customers 
Initial PDFs 
C-Spec Opt PDFs 
Generic Opt PDFs 
Admin Msgs 
To Stmt Gen WS 

Admin Msgs 

Total: 



5,000 
375 
6,250 



Lines Required (100% Utilization) 



Mb 



475 
20 
9* 



504 



475 
15 
375 



865 



From SGWS 


1,544 


128 


57.6 


Eff: 98% 


0.0 


0.0 


0.0 


To Customers 


28.8 


14.4 


9,6 


Net cps 


3,060 


1,530 


1,020 


Eff: 85% 


0.1 


0.2 


0.3 



Home Banking Software User Monthly Flows 



Statements 5.0 
Incoming PDF Traffic (Expected) 





Per Stmt 


kb 


AH Stmts 


kb 


Initial PDFs 


1.0 


95 


5.0 


' 475 


C-Spec Opt PDFs 


0.1 


5 


0.4 


23 


Generic Opt PDFs 


1.3 


75 


6.3 


375 


Total: 


2.3 


175 


11.6 


873 


nload Times (All Statements) 








Eff: Modem 


57.6 


28.8 


14.4 


9.6 


85% Net cps 


6,120 


3 t 060 


1,530 


1,020 


Seconds 


143 


285 


570 


855 


Minutes 


2.4 


4.8 


9.5 


14.3 



ePav System Data Flow Model 
INPUT Description 



Mature System, Rev 2 
Variable Name 



Base 



H 

01 
ft 



01 



Participant Counts 
Originator Count 
Originator Count, This SSP 
CSP Count 

Customer Count, Total 
Customer Count, This CSP 
Template Data 



CntOriginator 
CntOrigSSP 

CntCSP 
CntCustTotal 
CntCustCSP 



10,000 
2,500 
100 
2,500,000 
250,000 



Templates Per Originator 


TemplPerOrig 


2.0 


Monthly Template Update Size (kb) 


TemplUpdSize 


300 


Tries Per Update Success 


TemplUpdTries 


2.0 


Fraction Global Templates 


TemplGlobalFrac 


40% 


Statement Data 




Statements Per Originator Per Month 


StmtPprOrinMn 


9 nnn 


Statement Content Size (kb) 


StmtContentSize 


10 


PDF Data 






Sizes 






BSP Interactive Size (kb) 


PDFBSPIntSize 


40 


Access Req'd, C-Spec Size (kb) 


PDFReqdCSpecSize 


40 


Access Optional, C-Spec Size (kb) 


PDFOptCSpecSize 


60 


Req'd, Generic Size (kb) 


PDFReqdGenSize 


15 


Optional, Generic Size (kb) 


PDFOptGenSize 


60 


Counts 






Req'd, Generic, Count 


PDFReqdGenCount 


1.5 


Optional, Generic, Count 


' PDFOptGenCourit 


10 


Take Rates 






Access Optional, C-Spec Buy-In 


PDFOptCSpecBuyln 


25% 


Access Optional, C-Spec Take Rate 


PDFOptCSpecTake* 


40%- 


Optional, Generic, Take Rate 


PDFOptGenTake 


10% 


Communications Efficiencies 






Orig to SSP 


CommEffOrigToSSP 


85% 


SSP to SSWS 


CommEffSSPToSSWS . 


98% 


SSWS to eSwitch 


CommEffSSWSToeSwitch 


90% 


eSwitch to SGWS 


CommEffeSwitchToSGWS 


90% 


SGWS to CSP 


CommEffSGWSToCSP 


98% 


CSP to Customer 


CommEffCSPToCust 


85% 


Constants 






Mb/Mo per k-bits/sec 


Conv 





ePav System Flow Scenario- 



Mature System. Rev 2 



OUTPUT 



Statement Side Workstation Monthly Flows 



m 



Count 

Aggregate Incoming/Share 
From SSPs 

Template Updates 10,000 
Content Reeds 5,000,000 

Admin Msgs 

Total: 



Mb 



3,000 
50,000 



53,000 



ry 

m 

n 



Aggregate Outgoing 

to eSwrtch: 
Template Updates 
Content Reeds. 
Admin Msgs 

Total:" 



10,000 
5,000,000 



3,000 
50,000" 



53,000. 



o 
□ 

m 



Lines Required (100% Utilization) . 



From SSP: 


1,544 


128 


57.6 


Eff: 98% 


0.1 


1.3 


2.9 


ToeSwftcti: 


1,544 


128 


57.6 


Eff: 90% 


0.1 


1.4 


3.1 



Name 


kbits/sec 


$/Mo 


10QMbs 


100,000 


LAN 


T3 


44,184 


70,000 


16Mbs 


16,000 


LAN 


10Mbs 


10,000 


LAN - 


T1 


1,544 


2,000 


ISDN 


128 


100 


56K 


58 


150 


28.8 


28.8 


30 


14.4 


14.4 


30, 


9:6 


9.6 


30 



! 



eSwitch Monthly Rows 



Aggregate Incoming Count Mb 

Template Updates 40,000, 12,000 

Content Reeds 20,000,000 200^000 
Admin Msgs 

Total: 212,000 

Aggregate to Storage 

Template Updates 20,00.0 6,000 

Content Reeds 20,000,000 200*000 

Admin Msgs- 

Total: 206,000 

Aggregate Outgoing 

Template Updates 812,000 243,600 

Content Reeds 20,000,000 200,000 

Admin Msgs ' 

Total: 443,600 

Lines Required (100% Utilization) 

From SSWS: 1,544 128 

Eff: 90% . 0.5 5.6 

To SGWS: 1,544 128 

Eff: 90% 1.0 11J 



Statement Generation Workstation Monthly Flows 



Aggregate Incoming Count Mb 

From eSwitch 

Template Updates 9 t 200 2,760 

Content Reeds 2,000,000 20,000 
Admin Msgs 
From CSP 

Admin Msgs 

Total: 22,760 

PDFs Per 1000 Statements 

^ BSP Interactive 1,000 40 

Acc Req'd, C-Spec 1,000 40 

^ Acc Optional, C-Spe 250 15 

Req'd, Generic 2 0 

Optional, Generic 10 i_ 

^ Total: 96 

j? Aggregate Outgoing:/ Share* 

To CSP 

?S Initial PDFs 2,000,000 205,000 

Wi - C-Spec Opt PDFs 500,000 ' 20,000 

f : Generic Opt PDFs 92,000 10.179 
^ Admin Msgs 
^ To eSwitch: 

Admin Msgs 

2 Total: 235,179 

~ ; Lines Required (1 00% Utilization) 



From eSwitch 


1,544 


123 


57.6 


Eff: 90% 


0.0 


0.6 


J'-3 


To CSP 


1.544 


128 


57.6 


Eff: 98% 


0.5 


57 


12.7 



CSP Home Banking Software Monthly Flows 



Aggregate Incoming / Share 

Count Mb 

From Stmt Gen WS 

Initial PDFs 2,000,000 205,000 

C-Spec Opt PDFs 500,000 20^000 

Generic Opt PDFs 92,000 10,179 
Admin Msgs 

^ Total: 235,179 

tfl Aggregate Outgoing / Share 
To Customers 

H Initial PDFs 2,000,000 205,000 

O C-Spec Opt PDFs 200,000 8,000 

£L Generic Opt PDFs 2,000,000 120,000 

y Admin Msgs 

S To Stmt Gen WS 

y Admin Msgs 

□ 



5 



Total: 333,000 



Ti Lines Required {100% Utilization) 



From SGWS 


1,544 


128 


57.6 


Eff: 96% 


0.5 


57 


12.7 


To Customers 


28.8 


14.4 


9.6 


Net cps 


3,060 


1,530 


1,020 


Eff: 85% 


41.3 


8Z7 


124,0 



Home Bank ing Software User Monthly Flows 



Statements 



8.0 



ttl 



an 



Incoming PDF Traffic (Expected) 

. Per Stmt 

Initial PDFs 
C-Spec Opt PDFs 
Generic Opt PDFs 
Total: 

Download Times (All Statements) 

Eff: 
85% 




1,348 



Modem 


57.6 


28.8 


14.4 


9.6' 


Net cps 
Seconds 
Minutes 


6,120 
220 
3.7 


3,060 
441 
7.3 


1,530 
881 
14.7 


1,020 
1,322 
22.0 



5 



m 
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C. Calculation Methods 

This section explains the spreadsheet calculations using the mature case output as an 
n^nrf i P T of output shows data flows incoming and outgoing from a network 
node, and shows the number of communication lines required by type. 

1 . ESP Statement Origination Workstation Monthly Data Flows 

Dataflows at ; the ESP Statement Origination Workstation are due to 

w Template updates and Statement content. Template updates are expected to 

^ <; onsist Pnmanly of changed enclosures and associated distribution logic 

W Changes to the principal Statement document (e.g. the main invoice) are 

*fj expected to be relatively infrequent. 

A There are 10 »°00 Template updates per month since there are assumed to be 

j£ 2 ' 500 originators served by this SSP, each of which has an average of 2 

% Templates active 1 , and there are assumed to be 2 attempts required per 

J* successful registration of a Template update (10,000 = 2,500 * 2 * 2). This 

^ corresponds to 3,000 Mb of Template data flow because the size of 

M (compressed) Template updates is assumed* to average 300 kb. 

q There are 5,000,000 content records passed through this Workstation 

ifl because this SSP is assumed to serve 2,500 originators, each of whom 

~ produces an average of 2,000 electronic statements per month (which might 

correspond to a 20 percent ESP share of a 10,000 statement per month 
? , biller). Because content records are assumed to be 10 kb each*, this 

corresponds to 50,000 Mb of content data per month 4 . 

q Because the spreadsheet does not model administrative message traffic or 

y3 data flow to and from the authoring workstation, incoming and outgoing 

^ data flow are identical. For estimation purposes, it is unlikely that 

m administrative message traffic would exceed 10 percent of the total traffic. 

Although it is anticipated that connections between the ESP Statement 
Origination Workstation and the SSP System will be by LAN, calculations 
are shown nevertheless for telecommunications links. A single Tl line 



There is some uncertainty about the average number of Templates Originators may wish to maintain. Simplicity 
suggests they maintain just one. On the other hand, multiple Templates may prove useful for different classes of 
Customers, e.g. residential va commercial, high-bandwidth vs. low-bandwidth, etc. 

1 This assumption of 300 kb per incremental update corresponds to 6 new enclosures per month, most of which would 
presumably be optional offers. Currently credit card bill typically include 3 new enclosures per month. These new 
enclosures might be selected via demographic logic from a library of 10 enclosures, some of which changed each 
month. Alternately, multimedia features could account for large template updates. 

' The assumption of 10 kb of content data per Statement is quite generous for the average statement. Fixed format 
Statements like typical utility bills have less than 500 bytes of Customer- variable content data per Statement. On the 
other hand, telephone bills can contain a large amount of variable data. The ability to provide optional personalized 
detail may actually provide incentives for Originators increase Statement content since only those who want it will 
get it. 

4 For purposes of comparison, consider that one of the largest Statement Services Providers (SSPs) now in operation 
received about 2 Gb/hour or about 1,500*000 Mb/month of print stream data. If this Provider were to convert 20 - 
percent of his present volume to ESP, the resulting operations would be about 6 times larger than the current 
example. 
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operating between 2 and 3 hours per day could transmit the required data 
from the Statement Origination Workstation to the ePay Switch. 
Alternately, two ISDN dial-up lines operating at about 75 percent of 
continuous capacity could accomplish the same transfer. 

2. ePay Switch Monthly Data Flows 

Since the SSP in this case is assumed to service 25 percent of all Statement 
Originators, it follows that the ePay Switch's aggregate incoming flow is 
four times the Statement Origination Workstation outflow. 

New incremental storages at the ePay Switch is approximately the same as 
incoming flow, the only difference being rejected Template updates. Active 
disk-based storage will increase by about 7.6 Gb per month, less deletions. 
Modular high capacity disk storage systems are available that can be 
incremented in 54 Gb blocks. Archival storage of content data via CD-ROM 
^ will be at the rate of 200 Gb per month, or 40 CDs per day. These CDs will 

^ be available for screened statistics and for secure investigations by Visa 

personnel. 

O 

p Data flowing from the ePay Switch is multiplied by the need to broadcast 

flJ Templates to multiple CSPs. The value of the multiplier depends on the 

jg weighted coverage fraction of Templates in the entire ESP system, called 

p here the Global Template Fraction. This fraction is one if every Template 

,jj is distributed to every CSP; i.e. if all Templates are global. The fraction is 

I ft zero if every Template is used by just one CSP; i.e. if all Templates are local. 

j ' Herein, the global Template fraction is assumed6 to be 40 percent. In the 

i . present case, it is assumed that 40 percent of the Templates (8,000) are 

Jl global and hence are sent to all 100 CSPs, and that the remaining 60 percent 

"rz are local and sent to just one CSP. Hence 812,000 Templates are sent from 

^ the ePay Switch (812,000 = 0.4 x 20,000 x100 + 0,6 x 20,000x1). The 

J3 upper bound for the number of Template updates sent is 2 million (100 x 

20,000) and the lower bound is just 20,000. This translates into 244 Gb per 
U! month of Template updates flowing from the ePay Switch, which is 

somewhat more than the 200 Gb of content data flowing through the ePay 

Switch!. 

About 30 ISDN dial-up lines operating at 50 percent capacity would be 
sufficient to handle both incoming and outgoing traffic. High capacity 
factors can be achieved because. the ePay Switch will operate in a polling 
mode, calling its workstations in sequence as soon as it can process 
additional data; High volume workstations may profit by using dedicated Tl 
lines. 



5 Statement Content data is stored at the ePay Switch for research purposes. It is likely that only several days of data 
will be kept on disk, with the remainder being archived to CD-ROM. The bulk of the ePay Switch's storage will be for 
Templates and Template Updates. 

6 Although bounded, this fraction is quite uncertain. Twenty percent may be an underestimate. Nominally local 
Statements like those from the Honolulu Water District could be more global than expected. One Sacramento 
resident and one Vancouver resident might own a vacation home in Hawaii and pay their water bills from their 
principal residences, making it necessary for their presumably local CSPs to keep a copy of the Honolulu Water 
District template. 

7 As shown in the equation above, This tendency for Template data to exceed Statement Content data increases with 
the number of CSPs and the Global Template Fraction. 
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3. ESP Statement Generation Workstation Monthly Data Flows 

The CSP in this example is assumed to service 10 percent of all ESP 
Customers. Accordingly it receives one tenth of all content records 
2,000 000 per month amounting to 20 Gb per month. It also receives 9,200 
Testes: 8 000 "global" Templates and 1,200 local Templates, amounting to 
another 2.7 Gb per month. Total Template storage requirements could reach 
SO Gb, depending on the rate at which Template resources are deleted from 
the system, and on default retirement policies. 

Templates and content records are transformed into Mandatory and 
Optional PDFs at the Statement Generation Workstation. For each 1 000 
Statements, the SGWS produces 8 , on average, 1,000 interactive panel'PDFs 
(e.g., containing buttons to retrieve optional enclosures), 1,000 mandatory 
personalized PDFs, 250 optional personalized PDFs (e.g. invoice detail), 2 
mandatory generic PDFs (e.g., regulatory notices), and 10 optional generic 
PDFs (e.g. promotions). Only 260 optional personalized PDFs are produced 
by the assumption that only 25 percent of Originators take advantage of this 
ESP capability. Generic PDFs are few because of their generic nature. 

The SGWS for this very large CSP is assumed to deliver 2,000,000 
statements per month, and consequently the SGWS shares to the CSPs 
System 2,000,000 initial PDFs, 500,000 optional personalized PDFs, and 
92,000 optional generic PDFs. Trie first figure is based on one initial PDF 
per Customer, a 25 percent sign-up rate on the part of Originators for 
optional personalized statements (e.g details), and 10 Optional Enclosures 
per Template for 9,200 Templates. The size of the initial PDF is the sum of 
the interactive PDF, the personalized mandatory PDF, and the expected 
number of generic mandatory enclosures time their average size. In this 
case, the initial PDF averages 102.5 kb (102.5 = 40 + 40 + 1.5 * 15). Thus 
the initial PDFs contribute 205 Gb to the SGWS outflow. The 500,000 
optional personalized PDF (e.g. statement details) comprise 20 Gb'of data. 
The optional enclosure PDFs comprise another 10 Gb of data per month, 
bringing the total outflow to 235 Gb per month. 

Incoming data could be handled by one ISDN line operating at 60 percent 
capacity. Data going out to the CSPs Home Banking System should be via 
network Bhare 9 . 

4. CSP Home Banking System Monthly Data Flows 

Data flows coming to the large CSP Home Banking System modeled herein 
are described above. Aggregate outgoing flows are the initial PDFs 
described previously: 2;000,000 initial PDFs comprising 205 Gb of data, 
200,000 optional personalized PDFs (the assumed 40% of the 500,000 
prepared by the SGWS) actually requested by Customers amounting to 8 Gb 



" Generic PDFb are not actually produced at the Statement Generation Workstation. Mandatory generic PDFs are 
appended to the mandatory personalized PDF to form the initial PDF. Optional generic PDFs are simply passed - 
along to the CSPs Home Banking Server for delivery on request by individual Customers. 

9 A standard 10 Mbits/sec Ethernet LAN is about 6 times faster than a Tl line. An Token Ring LAN is about 10 
times faster than a Tl line. The still Bomewhat exotic 100 MBits/sec Ethernet LAN is about 60 times faster. 
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t^ d «^, and , fi u ally „ 2,000,P00 0ptU}nal Aidb.Bn.10 requested in 

Aeaggregate by all comers which account for an additional So Gb 0 f 

IT nr k * a8 t ! 0Clated adver8e consumer reaction. On a 100 percent 
utilization basis, the number of outgoing 14 4 kbit.*/.™ H„„= , 
Q *ansmit the average of 8 ^o* J^to^ 

5 S^TJSSK^ two and five *~ *" — ^ "«S2» • 

p 5. CSP Customer Monthly Data Flows 

S SSSSf V 8 . 0 ^ U*WM. 14.4, and 28.8. kbits/sec modems at 85 

CO ™T? ^ m ™ MB efficiency, this implies download times of 22, 15, and 7 

5 minutes for all 8 statements, These estimates do not include a "list of 

- Statements screen that CSPS will likely prepare as a Table of Contents and 

I £aZ • ""I- ^ t\ erage SUltement WOuld downl ° ad complete^ le^ 

41 Srrt™ 11 ^ * ab *«? 88rve ™ that implemented Adobe's ByLsYrler 

transmi *non technology could offer their users considerably more rapid 
H. re sponse via the interlaced rendering it supports. 

5 d. Summary of Data Flow Projections 

S J^™^ Total 

^ £0^^?"^^ Additional 

2929 W m KgUre 3030 and S^P^^y ^ Kg««« 2828 and Figure 

E. Conclusions. 

The pilot is of such relatively small scale that data flows are easily managed using 
conventional equipment Storage requirements are within the capabilities of standard 
desktop machines. Communications could be accomplished using conventional 28.8 kbits/sec 
modems However to test more realistic production-level equipment and in anticipation of 
rapid system growth, we plan to test more robust equipment and ISDN communications. 
Although one would expect high data flows through the ePay Switch at system maturity, 
the flows through large CSP Home Banking Systems ™ also very large, so large as to 
suggest the need for architectural improvements prior to commercial release. In particular 
it would be desirable to cache as many statement resources as possible at the customer's PC 
Resources that might be cached could be entire PDF documents or document building 
blocks. The more promising approach is to cache the building blocks, such that they could 
be used in multiple documents. The idea would be to send down a PDF framework that 



One optional generic enclosure is expected to be requested since there is assumed to be a 10 percent take rate c 
the assumed 10 available generic enclosures. 
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